SYSTEM, METHOD AND STORAGE DEVICE FOR INTEGRATION, UNIFICATION AND DISPLAY OF PATIENT DATA THROUGH C

专利摘要:
abstract implementations provide a user of a mobile device access to patient information and patient physiological data. actions can include receiving a user request, the user request being received in response to the user input to the mobile device, determining that the user request is associated with a patient data and / or patient information stored in a plurality of data stores associated with a plurality of facility systems, each data store in the plurality of data stores being associated with a respective facility system, transmitting a plurality of requests, each request being directed to a respective facility system, receiving a plurality of responses, each response being responsive to a respective request of the plurality of requests, and transmitting the response to the mobile device, the response being responsive to the user request. abstract systems and methods for integrating, unifying and displaying patient data through continuous health care. The present invention relates to implementations that provide a mobile device user with access to patient information and patient physiological data. Actions may include receiving a user request, the user request being received in response to a user input on the mobile device; determining that the user request is associated with patient data and / or patient information stored in a plurality of data stores associated with a plurality of installation systems, each data store in the plurality of data storage being associated a respective installation system; transmitting a plurality of resistance, each request being directed to a respective installation system; receiving a plurality of responses, each response responding to a respective request from the plurality of requests; and transmitting a response to the mobile device, the response responding to the user request.
公开号:BR112015021229A2
申请号:R112015021229
申请日:2014-02-27
公开日:2020-03-10
发明作者:Williams Portela Alan；Vidal Pedraza Augustine Iv；Lee Blake Daniel；R Mcqueen Neil；Trey Moore Stephen；Cameron Powell William
申请人:Airstrip Ip Holdings Llc；
IPC主号:

专利说明:

Invention Patent Descriptive Report for SYSTEM, METHOD AND STORAGE DEVICE FOR INTEGRATION, UNIFICATION AND DISPLAY OF PATIENT DATA THROUGH CONTINUOUS HEALTH CARE. CROSS REFERENCE TO RELATED APPLICATIONS [001] This order claims the benefit of and priority for US Provisional Order N ^Q 61 / 771,591, filed on March 1, 2013, the exposure of which is expressly incorporated herein by reference in its entirety.
BACKGROUND [002] Patient information can be stored through multiple facilities associated with respective healthcare providers. For example, a health care continuum may include hospitals, clinics, laboratories and / or other healthcare facilities. In some cases, each healthcare facility had its own data source for storing patient information and data associated with services provided at the facility. For example, multiple different electronic medical records (EMRs) can be provided for a particular patient through a health care continuum. In some instances, these EMRs are vendor-specific storage data, and information is in disparate formats.
[003] Physicians and other health care providers may be required to access patient data and information through a health care continuum. The disparate nature, in which data and information can be stored, can complicate the retrieval and display of relevant patient information to healthcare providers.
SUMMARY [004] The implementations of this exhibition provide a method
Petition 870160024336, of 05/31/2016, p. 4/14
2/81 data for providing a user with a mobile device to access patient information and patient physiological data. In some examples, the methods include the action of receiving a user request, the user request being received in response to a user input on the mobile device, the determination that the user request is associated with patient data and / or to patient information stored in a plurality of data stores associated with a plurality of installation systems, each data store in the plurality of data storage being associated with a respective installation system, the transmission of a plurality of resistance, each request being directed to a respective installation system, the receipt of a plurality of responses, each response responding to a respective request of the plurality of requests, and the transmission of a response to the mobile device, the response responding to the user request. Other implementations of this aspect include corresponding systems, devices and computer programs, configured to perform the actions of the methods, encoded in computer storage devices.
[005] These and other implementations may optionally include, each, one or more of the following resources: the determination that the user request is associated with patient data and / or with a patient information stored in a plurality of patient stores. data includes access to a patient index with installation, based on a patient identifier for determining a plurality of installation systems, the patient identifier being included in the request; the actions also include the identification of installation systems included in the plurality of installation systems based on a provider index with installation, the provider index with installation mapping the device user
3/81 mobile for installation systems of the plurality of installation systems; the identification of installation systems is carried out based on a user identifier, the user identifier being provided in the user request; each request in the plurality of requests includes user credential data associated with the user of the mobile device; actions also include retrieving user credential data from an installed provider index, the provider index with patient mapping the mobile device user to installation systems from the plurality of installation systems; actions also include: analysis of the user request for determining patient data and / or patient information that meets the user request, and the generation of a chain based on patient data and / or patient information patient, the chaining including a set of tasks that include one or more tasks performed to meet the user request, in which the transmission of the plurality of requests is included in the set of tasks; actions also include: processing patient data and / or recovered patient information, patient data and / or recovered patient information being included in the plurality of responses, and generating the response that is to be provided for the mobile device; processing patient data and / or recovered patient information includes at least one of the generation of additional data based on patient data, the formatting of the recovered patient and / and patient data, and conditioning patient data and / or patient information; the actions still include conditioning the additional data; additional data includes data that can be processed by the mobile device to generate one or more data visualizations; conditioning of data and patient and / or patient information includes
4/81 at least one of data conversion based on a transmission protocol, formatting data for optimal display on the mobile device, and packaging data for transmission to the mobile device; actions further include determining that the user request is associated with a portion of patient data and / or patient information stored in a cache data store, the response to the mobile device being provided based on the portion of the patient data patient and / or patient information; the user request includes a user identifier and a patient identifier, the user identifier and the patient identifier having the cross-reference referenced to one or more indexes for the identification of installation systems included in the plurality of installation systems; the actions still include authentication of the mobile device user; the actions still include the validation of the user request; and the response includes instructions, the instructions being executable by the mobile device for displaying patient data and / or patient information in an integrated view on the mobile device.
[006] Other aspects of the present exhibition provide systems including one or more processors, and a medium that can be read on a computer coupled to one or more processors having instructions stored there, which, when executed by one or more processors, cause one or more processors perform one or more of the methods provided there.
[007] It is appreciated that the methods according to the present presentation can include any combination of the aspects and resources described here. This means that the methods according to the present presentation are not limited to the combinations of aspects and resources specifically described here, but also include any combination of the aspects and resources provided.
5/81 [008] The details of one or more implementations are set out in the associated drawings and in the description below. Other resources, objectives and advantages will be evident from the description and drawings and from the claims.
DESCRIPTION OF THE DRAWINGS [009] The patent or filing of application contains at least one colored executed design. Copies of this patent or the publication of a patent application with colored drawing (s) will be provided by the Office upon request and payment of the necessary fee.
[0010] Figure 1 is a schematic illustration of an example system architecture according to implementations of the present exhibition.
[0011] Figure 2 is a schematic illustration of another system architecture according to implementations of the present exhibition.
[0012] Figure 3 is a diagram of functional blocks of an example system according to implementations of the present exhibition.
[0013] Figure 4 is a more detailed view of the functional block diagram in figure 3.
[0014] Figure 5 describes an example platform for the provision of integrated and unified views of patient data and patient information.
[0015] Figure 6 describes example components and subcomponents that can be included in the core components of Figure 5.
[0016] Figures 7 to 16B describe graphical example user interfaces (GUIs) for the provision of integrated and unified views of patient data and patient information in accordance with the implementation of the present exhibition.
[0017] Figure 17 is a flowchart that illustrates an example process that can be performed according to implementations of the present exhibition.
[0018] Same reference symbols in the various drawings indicate the same elements.
DETAILED DESCRIPTION [0019] The implementations of this exhibition are generally aimed at a scalable mobility architecture for the company, data agnostic and vendor to securely deliver patient data and information from medical devices, electronic medical records (EMRs) and patient monitors for healthcare providers anywhere through a healthcare continuum. More particularly, the implementations of the present exhibition provide integrated and unified views of patient data and patient information on mobile devices (for example, smartphones, tablets) from a plurality of data sources through the healthcare continuum. As discussed in more detail here, the implementations of the present exhibition enable timely and collaborative clinical decision-making, and enable healthcare systems to better track quality measures, strengthen a mobile workforce, expand networks and achieve a clinical transformation.
[0020] Referring now to Figure 1, an example system architecture 100 is illustrated, and includes a mobile device 102, connectivity interface (s) 104, a network 106, a first installation system 108 and a second installation system 110. As discussed in more detail here, data is transferred from each of the first and second installation systems 108, 110 via network 106 and connectivity interface (s) 104 for presentation or display on the mobile device 102. In addition, data can be transferred from the mobile device 102 via connectivity interface (s) 104 and network 106 to each of the first and second installation systems 108, 110. Although a single mobile device 102 is illustrated, it is contemplated that one or more mobile devices 102 can communicate with each of the first and second installation systems 108, 110 via network 106 and the connectivity interface (s) 104. Similarly, although two installation systems are illustrated, implementations of the present exhibition may include one or more installation systems.
[0021] The mobile device 102 can include any number of sample devices. These sample devices include, but are not limited to, a mobile phone, a smartphone, a tablet computing device, a personal digital assistant (PDA), a laptop personal computer (PC), a desktop PC and / or appropriate combinations of themselves. In the example described, the mobile device 102 includes a display 122, a processor 124, a memory 126, an input interface 128 and a communication interface 130. Processor 124 can process instructions for carrying out implementations of the present exhibition. Instructions may include, but are not limited to, instructions stored in memory 126 for displaying graphical information on display 122. Sample displays include, but are not limited to, a thin film transistor liquid crystal display (LCD) ( TFT), or an organic light emitting diode (OLED) display. Memory 126 stores information on the mobile device 102. In some implementations, memory 126 may include a volatile memory unit or units, and / or a non-volatile memory unit or units. In other implementations, removable memory may be provided, and may include, but is not limited to, a memory card. Sample memory cards in
8/81 include, but are not limited to, a secure digital memory (SD) card, a miniSD memory card, a USB flash drive, and the like.
[0022] In some examples, input interface 128 may include a keyboard, a touch screen, a mouse, a trackball, a microphone, a touchpad and / or appropriate combinations thereof. In some implementations, an audio encoder - decoder (not shown) can be provided, which receives an audible input from a user or another source through a microphone, and converts the audio input into usable digital information. The audio decoder encoder can generate an audible sound, such as through a loudspeaker that is provided with the mobile device 102. Example sounds can include sound from voice phone calls, recorded sound (for example, messages voice, music files, etc.), and / or sound generated by applications operating on the mobile device 102.
[0023] The mobile device 102 can communicate wirelessly through the connectivity interface (s) 104, which may include a digital signal processing circuit. Connectivity interface (s) 104 can provide communications under various modes or protocols, including, but not limited to, GSM voice calls, SMS, EMS or MMS, CDMA, TDMA, PDC, WCDMA, CDMA2000, and / or GPRS. This communication can take place, for example, through a radio frequency transceiver (not shown). In addition, the mobile device may be capable of short-range communication using features including, but not limited to, Bluetooth and / or WiFi transceivers (not shown).
[0024] Mobile device 102 communicates with network 106 through connectivity interface (s) 104. In some instances, connectivity interface (s) 104 may include a satellite receiver , a cellular network, a Bluetooth system, a WiFi system
9/81 (for example, 802.x), a cable modem, a DSL / dial-up interface, a private telephone exchange (PBX) system, and / or appropriate combinations thereof. Each of these connectivity interfaces 104 allows data to be transmitted to / from network 106. In some instances, network 106 can be provided as a local area network (LAN), a wide area network (WAN), a Wireless LAN (WLAN), a metropolitan area network (MAN), a personal area network (PAN), the Internet, and / or combinations thereof.
[0025] In the example systems of figures 1 and 2, the first installation system 108 includes a plurality of installations 140, and the second installation system 110 includes an installation 140. It is contemplated that each installation system 108, 110 may include one or more installations, and is not limited to the example arrangement described here. In the case of multiple facilities, the facilities may be located remotely from each other, and / or may be located in a common or local location (for example, separate departments in a common building (the same)). Each installation system 108, 110 can be provided as a medical care system, for example, whose medical care system can include one or more hospitals, hospital systems, clinics, doctors' offices and the like.
[0026] In some examples, each facility 140 includes an associated information system 142, computer interface (s) 144 and patient monitoring device 146. Example information systems may include, but are not limited to, a clinical information system (CIS), an EMR system, an electronic health record system (EHR), and / or a hospital information system (HIS). Each information system 142 can be provided as a server and support the acquisition, storage, modification and
10/81 distribution of clinical information, such as patient data, throughout facility 140 and / or facility system 108, 110. In some instances, each information system 142 may be communicating with one or more auxiliary information systems (not shown) which may include, but is not limited to, a pharmacy management system, a laboratory management system, and / or a radiology management system. Although example system architecture 100 includes an information system 142 located at each facility 140, it is contemplated that facilities 140 can communicate with a common information system 142 that is located remotely from any facility 140, or that is located at one of the installations 140 in the installation system 108, 110.
[0027] In some examples, computer interface 144 can communicate with information system 142 to allow access to information that is stored in and managed by information system 142. In some examples, computer interface 144 can include a personal computer (PC) (for example, desktop, laptop, or tablet). Although a single computer interface 144 is illustrated in the example architectures described here, it is contemplated that one or more computer interfaces 144 can communicate with information system 142. Communication between each computer interface 144 and information system 142 it can be obtained through a direct connection, or remotely through a network (not shown) which may include, but is not limited to, a LAN, a WAN, a WLAN and / or the Internet.
[0028] In some examples, each patient monitoring device 146 monitors the physiological characteristics of a particular patient 150, and generates data signals based on that. As discussed in more detail here, the implementations of this
11/81 exhibition provides patient monitoring devices that include a computing device, such as a tablet computing device. The data signals are communicated to the information system 142, which collects the patient data based on them, and stores the data for a patient record that is associated with the particular patient. An example patient record can include an electronic medical record (EMR). Although a single patient monitoring device 146 is illustrated for each patient 150, it is envisaged that multiple patient monitoring devices 146 can monitor a particular patient 150. Patient monitoring device (s) 146 can communicate with information system 142 over a direct connection, or remotely over a network (not shown) that may include, for example, a LAN , a WAN, a WLAN and / or the Internet.
[0029] In some examples, patient data is made available for display on the computer device 144. A healthcare provider (for example, a nurse and / or a doctor) can increase patient data by entering a patient information that is also stored on the computer device 144. More specifically, the healthcare provider can enter patient information corresponding to a particular patient 150, whose patient information can be stored in the patient record ( for example, EMR). As an example, a nurse can enter nursing notes, whose nursing notes can be stored in the patient record in the information system. Sample patient information can include any non-physiological information corresponding to a patient (for example, name, age, date of birth (DOB), sex).
[0030] As discussed above, each information system 142
12/81 stores patient data that can be collected from patient monitoring devices 146, as well as additional patient information, which may include information that is entered by a healthcare provider. The information system 142 communicates patient data and / or additional patient data to a data management system (DMS) 160. The DMS 160 can be provided as a server or a virtual server, which runs software components from server, and may include a data store including, for example, a database and / or flat files. In the example system architecture 100 of Figure 1, each installation system 108, 110 includes a corresponding DMS 160. In such an arrangement, each information system 142 communicates patient data and / or additional patient data to the DMS 160. Furthermore, and as discussed in greater detail below, the DMS 160 can communicate auxiliary information to the information system. information 142. Communication between the DMS 160 and the information system (s) 142 can be achieved through a direct connection or remotely over a network (not shown) which may include, for example, a LAN, a WAN, a WLAN and / or the Internet.
[0031] In some examples, a DMS 160 corresponding to a particular installation system may be located remotely from any of the facilities 140 of the installation system 108, 110, or it may be located in a particular installation 140 of the installation system 108, 110. In the example system architecture 100 in Figure 1, the DMS 160 is located remotely from any facility 140 in each of the installation systems 108, 110. It is contemplated, however, that the DMS 160 may be located in a from facilities 140, and remote from other facility 140.
[0032] In the example system architecture 100 'in Figure 2, a
13/81
DMS 160 'is provided, which is common for (the same for) installation systems 108, 110. For example, DMS 160' can be described as being common to several installation systems 108, 110, and is not associated with an installation system 108, 110 in particular. For example, DMS 160 ’can be hosted by a third party vendor (for example, a cloud service provider). In some instances, each information system 142 communicates with the DMS 160 'over a direct connection, or remotely over a network (not shown) which may include, but is not limited to, a LAN, a WAN, a WLAN and / or the Internet. In the example arrangement in Figure 2, DMS 160 'communicates with each of the information systems 142 via network 106. The information systems 142 communicate patient data and / or patient information to DMS 160', and DMS 160 'can communicate auxiliary information to information system 142, as discussed in more detail below.
[0033] In the example system architecture 100 of figure 1, installation 140 or installation system 108, 110 installs DMS 160 as a local DMS, and DMS 160 is at the local site with other servers that may include, for example, example, the information system 142. In some implementations, the DMS 160 can be sectioned or separated from a logical network perspective, but it still physically exists with other servers that belong to the respective installation 140. In some examples, the server components are installed on DMS 160, whose components may include, for example, a database component, a database synchronization component, a web services component, and / or a structured query language (SQL) component. An information system interface can also be installed on the DMS 160, and functions as the interface for information system 142. As an example
14/81 pio, the information system interface may include OBLink, provided by GE Healthcare. In some implementations, the DMS 160 can be arranged in a multiple server configuration, where one server only hosts services related to web service and is logically segregated, and another server has the necessary server components remaining installed.
[0034] The example system architecture 100 ’in figure 2 provides the remote location of data collection on DMS 160’. In these implementations, the DMS 160 'can be provided at a third party site, remote from any of the facilities 140 or the installation systems 108, 110. The third works as a DMS hosting, and the necessary server components are installed on the DMS 160 'hosted remotely. In some implementations, a business-to-business (B2B) virtual private network (VPN) can be created between the remotely hosted DMS 160 'and the network of installation 140 or installation system 108, 110. In this way, installation 140 and / or installation system 108, 110 forgo the purchase and / or maintenance of another physical server, or DMS 160. Also, the uptime and availability status of the DMS 160 'are easier to manage on the part of a dedicated third party. DMS access to the network can be served by third parties, as opposed to overloading installation 140 or installation systems 108, 110. In addition, third parties can implement virtual server technologies to leverage multiple DMS installations on a single physical server . In these implementations, a plurality of virtual servers are logically partitioned into a single physical server, and each virtual server has the ability to run its own operating system and server components, and can boot independently.
[0035] According to the implementations of the present exhibition, the DMS 160, 160 ’synchronizes and transfers data between the mobile device
15/81
102 or multiple mobile devices 102 and the information system 142 or multiple information systems 142. More specifically, the DMS 160, 160 'processes and prepares patient data and / or patient information for transfer to and display on the mobile device 102 or on multiple mobile devices 102, from information system 142 and / or other systems, as discussed in more detail here. The DMS 160, 160 'also processes and prepares auxiliary information for transfer to and storage in the information system 142 from the mobile device 102, or multiple mobile devices 102 for potential presentation on a corresponding computer device 144. Sample DMSs may include, but are not limited to, the AirStrip server provided by AirStrip Technologies, LLC, whose AirStrip server includes AirStrip server components installed there.
[0036] Referring now to figures 3 and 4, an example module structure or system 300 that can be implemented to provide resources for the present exhibition will be described in detail. In some examples, the sample system 300 allows patient data and patient information to be communicated to / from and exchanged between mobile devices and data sources through healthcare continuums. In some examples, each module may be provided as one or more computer executable programs that are run using one or more computing devices (for example, computing devices provided as part of a DMS, computing devices located on one or more more installations of an installation system). [0037] Figure 3 illustrates an overview of the example system 300. In the example described, the module structure includes modules located on a DMS 301, a first installation system 302 and a second installation system 304. In some examples, the first
16/81 installation system 302 and second installation system 304 can be included in at least a portion of a health care continuum, discussed in more detail here. Installation system 302 includes a patient record module 303 (for example, the EMR module) that accesses one or more patient records managed and stored by the installation system 302. Installation system 304 includes a patient record module patient 305 (for example, an EMR module) that accesses one or more patient records managed and stored by the 304 installation system.
[0038] In the example described, and as discussed in more detail here, patient data and / or information can be provided for an integrated and unified display on the mobile device 102 over the network 106 and the DMS 301 through care continuums. health (for example, installation systems 302, 304). In some examples, patient data and / or information may be provided for display on a mobile device 102 ', 102 ”via network 106 from an installation system (for example, installation system 302, 304) . In some examples, mobile devices 102, 102 ’, 102” are the same device. That is, for example, a mobile device can receive patient data and / or information through a healthcare continuum, and / or from individual installation systems.
[0039] In some implementations, DMS 301 includes a web module 310, a hosting module 312, a data cache module 314 and an adapter module 316, a web module 320, a hosting module 322, a data cache module 324, a 326 collector module. In general, DMS 301 modules allow DMS 301 to retrieve and combine data from multiple installation systems (for example, installation systems 302,
17/81
304) through continuous health care. In some examples, the web module 310 provides a first-level network interface for the DMS infrastructure. In some instances, and in response to a request from a mobile device (for example, from mobile device 102), web module 310 performs request validation and user authentication, and routes the request to the request module. hosting 312. In some examples, web module 310 includes one or more submodules. Sample submodules include a request validation submodule, which validates incoming requests, a user authentication module, which authenticates a user and / or mobile device identity from which a request is received, and a submodule request routing, which routes requests after validation and authentication.
[0040] In some implementations, the hosting module 312 orchestrates the request processing. In some examples, the 312 hosting module includes one or more submodules. Sample sub-modules include a request analysis sub-module that parses received requests, a routing assembly sub-module, a routing processing sub-module, an operation execution sub-module, a data access sub-module, a formatting sub-module results, an access control sub-module, an encryption sub-module, a data conditioning sub-module, and a record history sub-module. In some examples, the hosting module 312 parses a received request (for example, using the request analysis sub-module) to determine, for example, what type of device issued the request, which application running on the device issued the request. requisition, and / or patient data / information (or other data, such as analytical data, discussed
18/81 of the ones below) are necessary to fulfill the request. In some examples, and based on the parsed information, the hosting module 312 builds a route (for example, using the routing assembly submodule). In some examples, a pipe can be provided as a task list, which needs to be performed to fulfill the request. Example tasks may include retrieving patient data / information in particular, processing retrieved patient data to generate additional data and / or data visualizations (for example, analytical data, trend graphs, discussed below), data recovered from encryption / decryption, generation of job log histories.
[0041] In some implementations, the hosting module 312 coordinates data retrieval with the data cache module 314 (for example, using the data access submodule). The recovered data is provided back to the hosting module 312. In some instances, the hosting module 312 processes the recovered data (for example, using the operation execution submodule, the result formatting submodule and / or the submodule conditioning). In some examples, the retrieved data is processed for the generation of additional data (for example, data used for data visualizations). In some instances, the recovered data and / or additional data is conditioned to the provision of an efficient transfer back to the requesting mobile device. In some examples, conditioning may include converting data based on a transmission protocol, formatting data for optimal display on the particular device, and / or packaging data for sending to the requesting device.
[0042] In some implementations, the data cache module
19/81
314 allows access to and optimal storage of detailed patient data / information used by other components of the system 300. In some examples, the data cache module 314 includes one or more submodules and / or data stores. An example sub-module can include a cache services sub-module. In some examples, the data cache module 314 can operate in a direct pass mode (real-time mode) and a repository mode. In some instances, the patient data / information required to satisfy a given request can be accessed directly from a source system (for example, installation system 302, 304) in real time. In these examples, the data cache module 314 operates in a direct pass-through mode, retrieving patient data / information from multiple data sources and passing on patient data / information to answer the request. In some examples, an application program interface (API) or other programmatic mechanism can be used to request patient data / information. In some instances, in direct pass-through mode, patient data / information is not stored in a persistent data store accessed by the data cache module 314. In some implementations, it might be desired to improve recovery performance. Consequently, the data cache module 314 can store data identifiers and / or pointers in a persistent data store. When in direct pass-through mode, the data cache module 314 uses the adapter module 316 to perform actual data / patient information retrieval from one or more installation systems.
[0043] In some examples, patient data / information that is required to satisfy a request cannot be accessed directly from the installation systems (for example
20/81 pio, of installation systems 302, 304). In these examples, the data cache module 314 operates in the repository mode. In some instances, in the repository mode, the data cache module 314 stores a detailed copy of the patient data / information in the persistent data store. That is, for example, the stored patient data / information is stored at the DMS level, but has been retrieved from remote data sources (for example, data sources located in the 302 installation system). In some instances, when a request is made for patient data / information in the repository mode, the patient data / information is retrieved directly from the persistent data store (for example, via the cache services sub-module).
[0044] In some implementations, the adapter module 316 allows the recovery of patient data / information through healthcare continuum. Consequently, adapter module 316 can be referred to as a federated adapter module. In some instances, in response to receiving a request from the mobile device 102 for patient data / information from multiple data sources (for example, installation systems 302, 304), the data cache module 314 uses the adapter module 316 to retrieve requested patient data / information from multiple data sources. In some examples, the 316 adapter module communicates with local hosting modules (discussed in more detail below) for the respective installation systems.
[0045] In some implementations, the DMS 301 request processing operation is stateless. More particularly, DMS 301 modules handle each incoming request as a separate unit and, once a request is handled,
21/81 stores status information associated with a completed request. In other words, after DMS 301 has processed a request, DMS 301 (for example, modules in DMS 301 that handled the request) “forgets” that the request actually occurred. In this way, requests received subsequently are not influenced by (for example, handled based on) previously processed requests.
[0046] In some examples, the operation of the DMS 301 is stateless, but the DMS 301 can still provide a record history of handled requests (for example, using the record history sub-module). For example, a request record history can be accessed during a system 300 audit.
[0047] In some implementations, each installation system 302, 304 includes one or more local web modules 320, 330, one or more local hosting modules 322, 332, one or more data cache modules 324, 334, and one or more vocabulary service modules 328, 338. In the example described, installation system 302 includes one or more collector modules 326, and installation system 304 includes one or more patient record adapter (EMR) modules 336.
[0048] In some examples, each of the web modules 320, 330 provides functionality as discussed in a similar way above with respect to the web module 310. More particularly, the web modules 320, 330 operate at a local level (eg example, location for the respective installation systems 302, 304), each performing a request validation and user authentication, and routing requests to the respective local hosting modules 322, 332. For example, the web modules 320 , 330 can receive requests from the respective mobile devices 102 ', 102 ”, can validate the requests and authenticate the respective
22/81 users / mobile devices, and route requests accordingly. In some examples, each web module 320, 330 includes one or more submodules. Sample submodules include a request validation submodule, which validates incoming requests, a user authentication module, which authenticates a user identity and / or a mobile device from which a request is received, and a request routing sub-module, which routes requests after validation and authentication.
[0049] In some examples, each of the local hosting modules 322, 332 provides functionality as discussed similarly above with respect to the hosting module 312. More particularly, the local hosting modules 322, 332 operate at a local level (for example, location for the respective installation systems 302, 304), each orchestrating request processing. In some examples, the local hosting modules 322, 332 orchestrate a request processing for requests received from the mobile device 102 via DMS 301, and / or from the respective mobile devices 102 ', 102 ”via the respective modules web 320, 330. In some examples, each local hosting module 322, 332 includes one or more submodules. Sample sub-modules include a request analysis sub-module that parses received requests, a routing assembly sub-module, a routing processing sub-module, an operation execution sub-module, a data access sub-module, a control sub-module access and an encryption submodule.
[0050] In some examples, each of the local data cache modules 324, 334 provides functionality as discussed in a similar way above with respect to the data cache module 314. More approximately, the local data cache modules 324,
23/81
334 operate at a local level (for example, local to the respective installation systems 302, 304), each allowing access to and optional storage of detailed patient data / information used by other components of the 300 system. In some examples, each module data cache 324, 334 can operate in both a direct pass mode and a repossessed mode, as discussed above with respect to the data cache module 314. In direct pass mode, the local data cache modules 324, 334 retrieve patient data / information from one or more local data sources and passed on to patient data / information below to answer the request. In some instances, it might be desired to improve recovery performance. Consequently, local data cache modules 324, 334 can store data identifiers and / or pointers in a persistent data store. When in direct pass-through mode, local data cache modules 324, 334 use collector module 326 and patient record adapter module 336, respectively, to perform actual data retrieval of digital content from source local data (s) (for example, patient record module 303 and patient record module 305, respectively). In some instances when in direct pass mode, local data cache modules 324, 334 can write data back to the respective patient record modules 303, 305.
[0051] In some instances, patient data / information that is required to satisfy a request (for example, from the mobile device 102 ', 102 ”) cannot be accessed directly from local data sources (for example example, patient record modules 303, 305). In these examples, each local data cache module 324, 334 can operate in the repository mode. In some examples, in the repository mode, the data cache module
24/81 location 324, 334 stores a detailed copy of the patient data / information in the persistent data store. That is, for example, the stored patient data / information is stored at the local level, having previously been received from the local data source (s) (for example, the patient record modules 303 , 305). In some instances, when a request is made for patient data / information in the repository mode, the patient data / information is retrieved directly from the persistent data store (for example, via the cache services sub-module).
[0052] In some implementations, the collector module 326 and adapter module 336 are specific to the type of patient record module 303, 305, respectively. In the example in figure 3, patient registration module 303 can be accessed based on a particular message sending protocol. An example message sending protocol can include the Health Level 7 (HL7) message sending protocol. In some examples, the patient data / information provided based on these message sending protocols is restored by the data cache module 324. Consequently, requests for this data can be fulfilled based on an operation of the data cache module. 314 and / or the local data cache module 324 in the repository mode, as discussed above. In some instances, changes to patient records in patient record module 303 may trigger an update of patient data / information re-stored by data cache modules 314, 324. For example, collector module 326 may automatically receive a message from patient record module 303 in response to a change / update, trigger update / change of data / patient information reinstated.
25/81 [0053] In the example in figure 3, the patient registration module 305 supports programmatic interface access (for example, API). In some examples, the patient data / information provided via the programmatic interfaces is passed directly to the data cache module 314 and / or the data cache module 334. Consequently, requests for that data can be fulfilled based on operation of the data cache module 314 and / or the local data cache module 334 in direct pass mode, as discussed above. In this way, this patient data / information is not persistent for the data cache module 314, 334.
[0054] Although the example in Figure 3 describes installation systems 302, 304 having different types of patient record modules 303, 305, it is appreciated that installation systems can include any appropriate combination of types of patient record modules and any number of patient record modules (for example, patient record modules 303, 305) and their adapter modules (for example, modules 326, 336). In addition, although the example in figure 3 describes two installation systems, the implementations of the present exhibition are applicable in instances including any number of conducting wires.
[0055] In some implementations, vocabulary service modules 328, 338 perform a translation between vendor-specific vocabularies and a standard vocabulary. In this way, the patient data / information retrieved via modules 303, 305 uses a standard vocabulary to be provided back to the mobile device 102 in a unified manner. In this way, the patient data / information retrieved via modules 303, 305 uses a standard vocabulary to be provided back to the mobile device 102 in a unified manner. For example, the
26/81 patient record 303, 305 can each be provided by a respective third party (for example, a seller) and can record data / information based on a vocabulary that is specific to the particular seller. Consequently, data sources provided from different third parties may refer to the same data / information or type of data / information using different terminology. In some examples, each vocabulary service module 328, 338 is specific to a respective 303, 305. [0056] Figure 4 is a more detailed view of the function block diagram in figure 3, describing additional components of example system 300 In the example described, DMS 301 further includes a patient list import module 400, a patient participation portal module 402, a patient matching service module 404, a provider management module 406, a storage of patient information data 408 and a directory information data store 410. In some examples, the patient information data store 408 stores patient demographic information 420, a data pointer cache 422, an index of patient with provider 424 and a patient index with installation 426. In some examples, the directory information data store 410 stores a directory installer 430, provider directory 432, and provider index with installation 434.
[0057] In some implementations, the patient list import module 400 allows an initial and ongoing import of patient lists and patient demographic information for patients. In some examples, the patient list import module 400 provides an interface for receiving a patient list, for example, provided in a document that can be read on a computer, and processes the patient list to fill the store.
27/81 patient information data 408 (for example, demographic information 420). In some instances, the patient participation portal module 402 provides an interface that allows users (for example, an administrator) to establish relationships between patient data / information stored through healthcare continuums and patients in particular. In some instances, health care providers, facilities and / or installation systems through health care continuums may be included in a health care organization (for example, a health care organization (ACO)). In some examples, the patient participation portal module 402 allows a user to define relationships between multiple patient records (for example, based on the respective medical record numbers (MRNs)) for the healthcare organization. In some examples, a relationship information defined via the patient participation portal module 402 can be stored in the patient information data store 408.
[0058] In some implementations, the patient matching service module 404 can be accessed via the hosting module 312 and the patient participation portal module 402. In some examples, the patient matching service module 404 can be accessed accessed by an application running on a mobile device (for example, on the mobile device 102) via the 312 hosting module. In some examples, the patient combination service module 404 processes patient data and / or patient information for the identification of potential patient combinations between disparate data sources (for example, multiple different EMRs across the health care continuum). In some examples, patient information associated with confirmed combinations
28/81 calls (for example, confirmed by an administrator through the 402 patient participation portal module, confirmed by a healthcare provider using a mobile device via the 312 hosting module) can be stored in the data store patient information 408. In some examples, a patient combination user interface (UI) is provided (for example, displayed on a mobile device) and can be used by a healthcare provider to search for patients and establishment, registration and / or confirmation of relationships between patient records in different systems that are related to a single patient.
[0059] In some examples, demographic information 420 includes information that can be used to identify any patient that has been established in the system. In some examples, demographic information 420 can be used to search for patients, discussed in more detail here. Sample demographic information can include name, age and / or gender. In some examples, data pointer cache 422 stores identifiers associated with detailed patient data. In some examples, identifiers point to particular data stores, in which the patient data / information to be retrieved is stored. In this way, the recovery performance (for example, speed) can be improved. In some instances, the provider patient index 424 maps patients in particular to one or more health care providers, and / or health care providers in particular to one or more patients. For example, a patient can be treated by a plurality of health care providers (for example, members of a patient care team, discussed below). As another example, a health care provider can treat a plu
29/81 patient mortality. In some instances, the patient index with installation 426 maps patients in particular to one or more installations and / or installation systems. In some instances, a patient can be mapped to particular facilities based on the patient's respective MRNs at the respective facility. For example, a health care continuum for a particular patient can include a hospital and clinic. In this example, the patient index with installation can map the patient to the hospital's MRN and clinic's MRN.
[0060] In some implementations, provider management module 406 provides an interface (for example, a web portal) to allow members of a healthcare organization (for example, ACO) to update directory information health care provider and / or health care provider relationships with facility. For example, a doctor can be associated with one or more health care organization installation systems and credentials (for example, for logon and / or authentication) can be provided to allow a doctor to access patient data / information provided from one or more installation systems.
[0061] In some examples, installation directory 430 provides a directory of installations interfaced by the system (For example, DMS 301). In some examples, the installation directory 430 also provides configuration parameters to allow communication (a message sending) between the system and the computing devices associated with the respective installations. In some examples, provider directory 432 includes a directory of healthcare providers (for example, nurses, doctors, specialists and the like) who are able to access patient data / information through the system (for example, DMS 301). In some
30/81 examples, the provider index with installation 434 maps each healthcare provider (for example, in the provider directory) to one or more facilities. For example, a healthcare provider can treat patients in multiple facilities. In some examples, the provider index with installation 434 securely stores health care provider credentials for facilities to which the health care provider is mapped. For example, a healthcare provider may have first credentials for accessing patient data / information in a first facility, and may have second credentials for accessing patient data / information in a second facility. In some examples, the provider index with installation 434 supports a single subscription functionality discussed in more detail here.
[0062] An example data stream will be discussed to illustrate implementations of this exhibition. It is appreciated that the implementations of the present exhibition are also applicable to other data flows. The sample data stream can be initiated in response to a request received from a mobile device (for example, the mobile device 102). In some examples, the request includes a user identifier, a device identifier, a patient identifier, data and patient identifiers, patient information identifiers and additional data identifiers. In some examples, the user identifier can be used to determine the particular user who issued the request, and the device identifier can be used to determine the particular device that transmitted the request. In some examples, the patient identifier identifies the particular patient that is the subject of the request, the patient data identifiers identify the particular patient data that has been
31/81 requested, the patient information identifiers identify the particular patient information that was requested, and the additional data identifiers identify additional data that was requested. For example, patient data identifiers can indicate which patient vital sign data was requested, and additional data identifiers can indicate which vital sign alarm data and trend views of vital sign data were also requested.
[0063] In the example data stream, web module 310 receives the request and processes the request for validation of the request and for authentication of the user, who submitted the request (for example, based on the user identifier and / or the device identifier). Through validation and authentication, web module 310 provides the request for hosting module 312. The hosting module 312 processes the request, as discussed above. In some examples, it can be determined that the patient data / information required to fulfill the request can be provided from the data cache module 314 (eg, repository mode). In these examples, patient data / information is provided for hosting module 312 from data cache module 314. In some examples, it may be determined that that patient data / information required to fulfill the request is to be retrieved from one or more data sources through a patient health care continuum (for example, federated mode).
[0064] In some examples, if patient data / information required to fulfill the request are to be retrieved from one or more data sources through the health care continuum (for example, federated mode), information from requisition (for example, assembled by the hosting module
32/81
312, as discussed above) will be provided for adapter module 316 by data cache module 314. In some examples, adapter module 316 accesses information stored in directory information data store 410 for requesting data from one or more installation systems (for example, installation system 304). For example, adapter module 316 can be aware of which installation systems for retrieving patient data / information from (for example, based on the patient index with installation 426) and can access the provider index with installation 434 for retrieving user credentials for the particular provider (for example, a user who issued the request). In this way, the adapter module 316 can provide appropriate user credentials for the respective installation systems for retrieving patient data / information.
[0065] In some examples, the adapter module 316 sends requests to the identified installation systems, each request identifying patient data / information and providing appropriate user credentials. In some examples, the respective hosting modules (for example, the hosting module 332) of the installation systems receive the requests from the adapter module 316, and can process the requests as discussed in a similar way above with reference to the hosting 312. The respective hosting modules fulfill the requests and provide the requested patient data / information back to the adapter module 316. In some instances, the adapter module 316 provides the retrieved patient data / information for the hosting 312, which completes the request processing, as discussed above, and provides a response to the mobile device that issued the request.
33/81 [0066] As discussed in the beginning, the present exhibition provides a healthcare provider, or a user of the mobile device 102 with secure remote access to patient data and / or patient information. Sample patient data can include physiological data. In some instances, physiological data can be obtained from a patient monitoring device (s). In some instances, physiological data may be obtained from a local health care provider (for example, a nurse, or a doctor measuring blood pressure, temperature, heart rate). In some instances, physiological data can be recorded in one or more patient records (for example, EMRs). In the case of a maternity patient example, patient data may include information on the progress of delivery, such as cervical examination status, placenta status, number of pregnancies, number of deliveries, epidural status and / or whether the patient is trying to deliver naturally after a caesarean section (VBAC). In some examples, the terms patient information refer to information corresponding to a particular patient that is, for example, entered into the information system 142 by the local health care provider. Sample patient information can include the patient's name, the name of the doctor (s) assigned to the patient, the nurse (s) assigned to the patient, a facility ID , a patient bed identification, a summary of patient data and / or graph notes. The terms patient information also refer to patient information provided from one or more patient records (for example, EMRs).
[0067] The patient data and / or patient information provided to the user located remotely can be provided as real-time data and / or historical data and information. Patient data and / or patient information are communicated between the device
34/81 mobile positive 102 and DMS 160, 160 'using a secure connection that is established by the network 106. A secure login or subscription process is provided, which preferably complies with the provisions of Health Insurance Portability and Accountability Act (HIPAA). The secure signature authenticates the user identity of the mobile device 102 based on a unique user ID and password combination. Both the user ID and the password must be correct in order to establish secure communication between the mobile device 102 and the DMS 160, 160 ’.
[0068] In some examples, a census or patient list is provided, which captures a variety of the information and / or data described here, is associated with each of one or more monitored patients 150. A strip chart is also provided, in which patient data and / or information can be graphically presented to the user. In the case of an example of a maternity patient, fetal strip and maternal contraction information can be provided for a particular patient 150. More specifically, the particular patient 150 is selected from the patient list, and the information from patient and / or data are subsequently presented. The information and / or data presented may include a fetal strip and a maternal contraction waveform, the patient's name, the name of the hospital, the patient's room and / or the bed number, and the date and time . The strip chart can provide a real-time view of patient data, as well as a historical view of patient data. More specifically, the waveform display can be updated in real time, so that the mobile device user 102 observes patient data as it occurs and / or is recorded. The user can scroll through the waveform display to see historical patient data, as described in greater detail below.
35/81 [0069] Various navigation features can be provided to allow the user to manipulate a view of the waveform display. In some implementations, the user can zoom in to zoom in / out on the displayed image. In this way, the user can see very specific waveform information, and / or other waveform microcharacteristics when zooming in to zoom in or other waveform macrocharacteristics when zooming out, for example. In some implementations, the user can scroll forward or backward through the waveform display. In this way, the user can view historical patient data. [0070] A patient data display can also be provided. In some implementations, the display of patient data may overlap with the strip chart described here. In another implementation, the display of patient data can be provided as an overlay and / or as a separate display. The display of patient data may include, but is not limited to, the patient's name, age, fetal gestation, number of pregnancies, number of deliveries, cervical examination information and doctor's name.
[0071] The implementations of this exhibition can be carried out on any of several operating systems or platforms 302 associated with the particular mobile device 102. The sample platforms include, but are not limited to RIM's Blackberry, Apple's iOS and / or OS X, MS Pocket PC, Win Mobile (Pocket PC, Smartphone), Win Mobile (standard, professional), and / or other appropriate platforms (for example, Google Android, and HewlettPackard's WebOS, Microsoft Windows, Unix, Linux).
[0072] As discussed in detail here, the implementations of the present exhibition are aimed at systems and methods of providing integrated and unified views of patient data and patient information from disparate data sources and / or products. More
36/81 particularly, the implementations of the present exhibition provide integrated and unified views of patient data and patient information retrieved through a health care continuum. In some instances, the health care continuum may include a plurality of disparate sources of clinical data. In some instances, a source of clinical data may correspond to one or more of the categories of healthcare services. Sample categories can include emergency medical services (EMS), outpatient services, inpatient services, outpatient services, post-acute services, home services and independent services. Sample EMS can include emergency departments (for example, a hospital's emergency room (ER)), urgent care facilities and transportation (for example, ambulance). Sample outpatient services and / or inpatient services may include hospitals and / or emergency care hospitals (CAHs). Outpatient services may include clinicians, groups / doctors' offices, surgery centers and pre-acute care. Sample post-acute care services may include specialist nursing facilities, long-term care hospitals, rehabilitation centers and home healthcare. Independent sample services may include imaging centers (for example, MIR), oncology centers, laboratories, virtual call centers and convenience clinics.
[0073] Figure 5 describes an example platform 500 for the provision of integrated and unified views of patient data and patient information. The sample platform 500 includes one or more product applications 502 and core components 504. The sample platform allows the transfer of patient data / information to / from one or more data sources 506 for display on
37/81 a mobile device (for example, on the mobile device 102). In some examples, example platform 500 is provided as one or more computer executable programs that are run using one or more computing devices (for example, DMS 160, 160 '). Sample data sources 506 may include one or more medical devices (for example, bedside monitors), one or more EMRs, health information exchange (HIE) data 512, image data 514 (for example, X-ray data) and 516 sensor data.
[0074] In some implementations, example platform 500 may include a mobile application platform 520. An example mobile application platform 520 may include the mobile application platform exposed in Order US N ^Q 13 / 716.974, deposited on December 17, 2012, and which claims the benefit of Provisional Application US N ^Q 61 / 579,954, deposited on December 23, 2011, the exposures of which are expressly incorporated here as cooling in their entirety.
[0075] In some examples, the mobile application platform 520 separates a native graphical user interface (GUI) and operating system components from application logic. In this way, the mobile application platform 520 translates and interprets application logic into native languages of each mobile device operating system to / from what patient data / information is to be transferred, and encompasses unique properties, the features, function and usability of each operating system. In some implementations, the mobile application platform 520 embodies a model-based approach, in which one or more models are provided each model corresponding to a patient data / information view that is to be displayed on a mobile device. In some examples, and as discussed in May
38/81 or details here, standard models can be provided, which provide standardized views of patient data / information. In some examples, customized templates may be provided, and may include templates customized by a mobile device user.
[0076] In some examples, the mobile application platform 520 processes patient data / information based on a model that defines a view to be displayed on the mobile device. In some examples, the mobile app platform 520 generates instructions for displaying graphs based on patient data / information and the model, and provides instructions for the mobile device, the mobile device executing instructions for the provision of the view based on patient data / information model (for example, presenting patient data / information in a view displayed on the mobile device).
[0077] In some examples, 502 product applications may include medical software applications that enable mobility in healthcare. For example, products can enable patient information and patient data (for example, waveforms and other critical data from EMRs, bedside monitors and devices, pharmacy, laboratory and other clinical information systems) be accessed securely and natively by healthcare providers on mobile devices. Sample products may include an obstetrics (OB) product (for example, AirStrip OB provided by AirStrip Technologies, LLC), a cardiology product (for example, AirStrip CARDIO provided by AirStrip Technologies, LLC), a monitoring product patient (for example, AirStrip PATIENT MONITORING provided by AirStrip Technologies, LLC), and an EMR extension product (for example, AirStrip EMR EXTENDER provided by AirStrip Technologies, LLC).
39/81 [0078] Figure 6 describes example components and subcomponents that can be included in the core components 504 of figure 5. In some examples, each component and / or subcomponent may be provided as one or more computer executable programs that they can be performed using one or more computing devices (for example, DMS 160, 160 'computing devices from figures 1 and 2). In some examples, the core components provide secure data access and data transport, single signature and profile / context management, interoperability (data adapters and interfaces), intelligent message routing, master patient indexes (eg, EMPI ) and care collaboration.
[0079] In the example described, core components 504 include a security component 600, a component of care coordination and collaboration interfaces 602, a data integration component and workflow 604, a component of data adapters from source 606 and a service component 608. In the example described, security component 600 includes a single signature subcomponent 610 and a context subcomponent / user profiles 612. In the example described, the care coordination and collaboration interfaces component 602 includes a voice subcomponent 614, a video subcomponent 616, and a message sending subcomponent 618. In the example described, the data integration and workflow component 604 includes a patient index (or index) component 620 and a smart routing subcomponent 622. In some examples, the source data adapters component 606 may include the service subcomponents adapter services 624 (for example, adapter service module 324 of figure 3). In the example described, service component 608 includes a reporting subcomponent and
40/81 analysis 626, a clinical transformation subcomponent 628 and an implementation and support subcomponent 630.
[0080] In some examples, the single signature subcomponent 610 supports a single signature functionality, discussed here. In some examples, a user can be authenticated once (for example, by providing login credentials for an application running on a mobile device) and data access can be provided through a plurality of data sources, without being authenticated for. each data source individually. In some examples, the 612 context / user profiles subcomponent supports specific user customizations based on a user context and / or a user profile, as discussed in more detail here. Example contexts can include the user being a medical attendant at one hospital and a part-time physician at another hospital. In some examples, one or more profiles can be associated with the user, each profile reflecting one or more customizations associated with the particular user. For example, the user can customize a standard view that can be displayed on a mobile device, to provide a customized view. Consequently, after the user is authenticated, one or more user-defined views (customized by user) can be provided for the mobile device.
[0081] In some examples, the care coordination and collaboration interfaces component 602 supports collaboration between members of a patient's care team. For example, a patient care team may include a doctor, a consultant, a specialist, an intensivist and a nurse. In some instances, the voice subcomponent 614 provides voice-based collaboration between care team members (for example, teleconferencing). In some examples, the video subcomponent
41/81
616 provides video-based collaboration between care team members (for example, a video conference). In some examples, the message sending subcomponent 618 provides collaboration based on message sending among care team members (for example, SMS / MMS text messaging). In some instances, the care coordination and collaboration interfaces component 602 provides security in a remote collaboration between care team members (for example, a secure teleconference, secure videoconference and / or secure messaging).
[0082] In some examples, the data integration and workflow component 604 integrates data from a plurality of data sources, and routes the data for display on mobile devices. In some instances, the patient index (or index) component 620 provides one or more indexes for mapping users to facilities and / or patients. In some examples, one or more indexes may be provided for associating a user (eg, a doctor) with one facility or multiple facilities (eg, hospitals), for associating a patient with one facility or multiple facilities, and / or to associate a user with one or more patients. In some examples, an index can be based on an ACO. In some instances, ACO includes one or more health care providers through a health care continuum and can provide cross-access to patient data / information. In some examples, the smart routing subcomponent 622 provides an intelligent routing functionality, discussed above.
[0083] In some examples, the 606 source data adapter component provides adapter functionality. In the example described, service component 608 includes a subcomponent
42/81 of report and analysis 626, a clinical transformation subcomponent 628 and an implementation and support subcomponent 630.
[0084] As discussed in more detail here, patient data and patient information can be provided from one or more disparate patient data sources (for example, the examples described in figure 5). In some instances, a patient may be associated with one or more health care services through the health care continuum. Consequently, and for each patient, patient data and patient data can be distributed across the healthcare continuum. For example, a patient can be taken to a hospital by EMS (for example, ambulance), can be treated in a hospital emergency department (for example, an ER), can be in the hospital on an outpatient basis, can attend a rehabilitation center (for example, physiotherapy), can be under home health care (for example, with home nursing care) and patient samples can be sent to a laboratory for analysis (for example, a blood provided by an external laboratory). In this example, patient care in particular touches multiple implementations across the healthcare continuum, and each facility can generate its own patient data, patient information and patient records (EMRs).
[0085] In general, an EMR can be described as a digital medical record provided as an electronic document that can be processed (for example, read from / written to) by one or more computer programs running on one or more devices computing. In addition, each entity or organization (for example, clinic, hospital, doctor, rehabilitation center, laboratory) that treats a patient can include its own independent information system
43/81 which provides an EMR that is specific to the information system. Consequently, multiple disparate EMRs can be provided for a single patient through the healthcare continuum. In the context of the example above, a first EMR can be provided for the patient by an ambulance service that transported the patient to the hospital, a second EMR can be provided for the patient by the hospital, a third EMR can be provided for the patient by the rehabilitation center and an EMR room can be provided for the patient by a nursing company that is providing home nursing care for the patient. In some examples, and as mentioned above, EMRs can be generated from disparate information systems. Consequently, the format and syntax of an EMR may differ from the format and syntax of another EMR.
[0086] In some instances, historical patient data and information can be provided for viewing by a healthcare provider, as well as providing real-time patient data for viewing by the healthcare provider. Extending the above example, the patient can be readmitted to the hospital on an outpatient basis and can be connected to one or more patient monitoring devices that generate physiological patient data based on a patient's physiological activity. In accordance with implementations of the present exhibition, and as discussed in more detail here, patient data and information from one or more of the first EMR, the second EMR, the third EMR and the fourth EMR, as well as data from real-time patient information can be provided for viewing by a healthcare provider (for example, a physician attending to the patient) on a mobile device in an integrated and unified manner. For example, real-time and / or historical physiological patient data
44/81 can be provided for display by multiple products (for example, a cardiology product and a patient monitoring product). The implementations of the present exhibition allow the integration and unification of the patient's physiological data through the products.
[0087] In accordance with implementations of the present exhibition, patient data can be displayed to a user of a computing device. In some implementations, the user provides login credentials for an application that runs on the mobile device. For example, the application can open and can provide a login screen for the user to provide credentials. In some instances, credentials may include a personal identification number (PIN). If the PIN is not authenticated (for example, the user entry PIN is not the same as a pre-stored PIN), an error will be displayed. If the PIN is authenticated (for example, the user entry PIN is the same as a pre-stored PIN), a website screen or a base screen may be displayed. In some examples, authentication can be provided based on a personal identifier (for example, the PIN) and another identifier. In some examples, another identifier may include an identifier that is unique to a mobile device that the user is using. For example, the PIN and a unique device identifier can be provided for authentication.
[0088] Figure 7 describes a sample site screen 700. In some implementations the site screen 700 provides a GUI including one or more site icons that can be selected (for example, clicked) by the user. In some examples, a site may include a specific facility (for example, a hospital clinic), a system of facilities (for example, a hospital system including one or more hospitals, one or more clinics, and / or one or more laboratories , and the like). In some examples, an index (for example, an index
45/81 user - installation) can be accessed based on an identifier associated with the user, to determine one or more site icons that are to be displayed to the user. In some instances, in response to the PIN being authenticated, an identifier associated with the user can be provided for the DMS 160 ’, for example, by the mobile device 102 (see figures 1 and 2). In some examples, the DMS 160 'stores an index (for example, an installation user index) that is accessed based on the identifier. In some examples, the index maps the identifier associated with the user to one or more installations that the user is associated with. In response, DMS 160 'provides instructions for mobile device 102 for displaying site screen 700 including one or more site icons 702, 704, 706, 708, 710, 712, 714, 716, each site icon being a graphical representation of a facility installation to which the user is associated.
[0089] In some implementations, and as mentioned above, the user can be associated with more than one site (for example, 702, 704, 706, 708, 710, 712, 714, 716). In some implementations, the user is affiliated with a single site, which is included in a network that includes a plurality of intercommunication sites associated with it. In some instances, a site may include a medical center, a dispensary, a hospital, an infirmary, an operating room, a laboratory setting, a nursing station, a rest station, a sanatorium, a toilet or any other health facility. appropriate health care. In some implementations, the site screen 700 can provide a summary of each site and / or specific sites, to which the user is associated. In some examples, a site summary may include a plurality of selectable icons (for example, a site access icon, a site information icon, a patient information icon, etc.). In some implementations, each su
46/81 site mário can include attributes (for example, patient counts).
[0090] A user entry can be provided for the site screen 700, the user entry indicating a selection of a site icon from one or more site icons. In some examples, a user input may include touching a touch screen display with a finger (for example, the index finger), a pen and / or other pointing device, as well as a digital cursor and / or a keyboard.
[0091] In some implementations, a basic screen can be displayed. According to implementations of the present exhibition, and as discussed in more detail here, the base screen may include a menu. In some examples, the menu provides a GUI, through which the user can request the display of data / patient information. In some examples, the menu is a user-specific menu. In some examples, the menu is specific to one or more user contexts. In some examples, the menu is specific to a site selected by the user. In some examples, the base screen is displayed in response to user input on the site screen.
[0092] According to implementations of the present exhibition, a menu is provided as a slide menu that is animated in response to a user selection of an icon. In some examples, the menu can be animated, so that the menu appears to slide from an edge of the base screen (for example, the left-hand edge). In some examples, the menu is animated, so that the menu appears to slide to the edge of the base screen in response to a user selection of an icon from the menu.
[0093] According to implementations of this exhibition, the menu may include groups of icon. In some examples, icon groups can be provided as standard icon groups. For example, a standard icon group can be displayed in the menu, the
47/81 standard icon being agnostic for the particular user (for example, displayed to any user). In some examples, icon groups can include user-customized icon groups. For example, the menu can include a custom user icon group that is specific to (for example, that has been defined by) the user. In some examples, icon groups can include user-specific and / or site-specific icon groups. For example, an icon group can include a workflow icon group that is specific to the user's role (for example, an attending physician) in a specific facility.
[0094] Figures 8A and 8B illustrate example snapshots of a base screen 800 that includes a menu 520. The example base screen 800 of figures 8A and 8B is user specific and site specific. For example, the base screen 800 can be displayed in response to a user selection of a site icon (for example, site icon 704 in figure 7). Consequently, a site identifier 816 can be provided to indicate the site, for which the menu 802 is specific. In some examples, a request for the base screen is provided for the DMS 160 ’in response to a user selection of an icon from the 700 site screen. In some examples, the request indicates the site that has been selected. In some examples, a user - installation index can be accessed for determining a menu setting to be displayed on the base screen. For example, and for a given site (installation), the user may have an associated profile, user-defined patient groups, context-specific workflows and / or installation-specific workflows. Consequently, the DMS 160 'can provide instructions for displaying a user specific, site specific screen, such as the example base screen 800 of figures 8A and 8B. More particularly, instructions can include instructions for displaying
48/81 a user specific menu, site specific 802 for the base 800 screen.
[0095] In the example described, the 802 menu provides icons for initiating the respective data / patient information displays. In the 802 menu, icons are displayed in icon groups, or menu groups 804a, 804b. It is appreciated that more or less icon groups can be displayed. In the example of figures 8A and 8B, the icon group 804a can be provided as a standard icon group. For example, the icon group 804a includes the icons “My Patients” 806, “Recently Viewed” 808 and “Find Patients” 810. In some examples, icons 806, 808 , 810 are not specific to the user and / or the installation (for example, icons 806, 808, 810 are displayed regardless of the particular user and / or the particular installation. In some examples, the 804a icon group may be For example, the user can define a patient group (for example, “My Cardio Patients”, “My OB Patients”) and can associate one or more patients with the Consequently, an icon that is representative of a user-defined group can be displayed in the 804a icon group.
[0096] In the example of figures 8A and 8B, the icon group 804b can be provided as a user specific and installation specific icon group. For example, the 804b icon group may be representative of a workflow (for example, “Cardio” (cardiology)) associated with the user at the particular facility (for example, as indicated by identifier 816). Consequently, the icon group 804a can include icons that are relevant to the particular workflow. In the example described, the icon group 804b includes an “In Basket” icon 812 and an “EMS” icon 814. In
In some instances, a workflow may include one or more tasks to be performed by the user as part of the user's role in a particular installation.
[0097] In some implementations, a request can be provided for DMS 160 'in response to a user selection of an icon from the 802 menu. In the example of figures 8A and 8B, the user can select the “My Patients” icon ”806. In response, a request can be provided for DMS 160 ', the request indicating a request for a list of all patients to which the user is associated. The DMS 160 ’can provide a response that includes instructions for displaying a list of all patients associated with the user, and can include patient data / information for display. In some instances, in response to the user selection of the “My Patients” icon 806, the 802 menu is animated to slide to the edge of the screen.
[0098] Figure 8B illustrates an example snapshot of a “My Patients” screen 820, which can be displayed in response to a user selection from the “My Patients” icon 806 in figure 8A. In this example, and in response to selecting the “My Patients” icon 806, screen 820 displays patient icons 822 (graphical representations) for all patients that are assigned to the specific user for the particular facility (for example, a General Hospital ). In some examples, and in response to the request, the DMS 160 'accesses one or more patient indexes to identify which patients are assigned to the user at the specified facility. In some examples, DMS 160 'retrieves patient data / information for the identified patient (s) and provides instructions for the mobile device to display screen 820. In some examples, DMS 160' retrieves data / patient information from one or more data sources associated with the patient and / or the particular facility. In some examples, the data / information
50/81 of patients that are to be displayed on screen 820 can be retrieved from the local data store for DMS 160 ’. [0099] In some examples, an order in which patient icons are displayed can be determined by a fixed count (for example, the most recent patients the user has reviewed), and / or can be determined based on alerts (for example, example, patients requiring immediate attention). In some implementations, a user can scroll sideways (as shown in figure 8B) or scroll vertically to see other patient icons that are currently not visible on the 820 screen.
[00100] In the example of figure 8B, patient icons 822 each include patient information 824 and patient data 826. In the example described, example patient information 824 can include patient name, gender of the patient, an identifier associated with the patient, and the patient's date of birth (DOB). In the example described, the sample patient data includes heart rate (HR), ambulatory blood pressure (ABR), respiratory rate (RR) and oxygen saturation (SPO2). It is appreciated that implementations of the present exhibit may include additional and / or other patient data / information in a patient icon 822. In some instances, the patient data provided in patient icons 822 may include recorded patient data / information. In some examples, the patient data / information provided in patient icons 822 may include real-time patient data / information. For example, a patient icon 822 can be representative of a patient who is currently being monitored by one or more patient monitoring devices (for example, as described in figures 1 and 2), and the patient data displayed on the patient icon patient 822 can be updated in real time based on data provided from the monitoring device (s).
51/81 [00101] In the example of figure 8B, patient icon groups 830a, 830b are provided. In some examples, patient icon groups may correspond to the respective locations of patients in a facility, for which screen 820 is specific. In the example in figure 8B, screen 820 can be specific to the “General Hospital” installation (for example, the site icon 706 in figure 7), and the patient icon groups 830a, 830b correspond to the respective wings of the facility ( for example, west wing, east wing, respectively).
[00102] In some examples, by selecting the “Recently Viewed” icon 808 of figure 8B, a display screen (not shown) can be provided, on which the patient icons are provided for patients, whose patient data / information has been recently seen by the user. In some examples, the patient icons to be included in the “recently viewed” patient list can be determined based on a fixed count (for example, the last X patients the user saw), and / or can be determined based on over time (for example, patients seen by the user for the last Y hours or days).
[00103] As discussed above, screens 800, 820 of figures 8A and 8B are user specific and site specific. In some implementations, these screens may be user specific, but not site specific. For example, a site agnostic "My Patients" screen may be displayed and may include patient icons representative of all patients assigned to the user across all facilities to which the user is associated. In some instances, in policy to a user selection of a “My Patients” icon from a non-site specific menu, a request can be provided for DMS 160 ’. In some examples, and in response to the request, DMS 160 ’accesses one or more patient indexes to identify which patients are assigned to the user, regardless
52/81 within the installation. In some examples, the DMS 160 'retrieves patient data / information for the identified patient (s) and provides instructions for the mobile device to display the 820 agnostic site “My Patients” screen.
[00104] In some examples, by selecting a “Find Patients” icon (for example, the 810 icon in figure 8A), a search interface is provided. Figures 9A and 9B illustrate screen snapshots of a search interface 900. Figure 9A illustrates the example search interface 900, allowing a user to initiate a search for a particular patient. In the example described, the search interface 900 may include a search section 902 that includes a search box 904. In some examples, buttons may be provided for refining the search. For example, the search can be refined based on the patient's last name (as shown in figure 9A), sex, age or other specific patient data. In the example described, search interface 900 includes a search results section 906 for displaying search results (as discussed in more detail below with reference to figure 9B). In some examples, a 907 keyboard is displayed, allowing the user to enter a search query (for example, patient name or a portion of it). For example, the user can enter the first letters of a patient's last name (as shown in figure 9A).
[00105] Figure 9B illustrates the example search interface 900, providing search results 908 based on a user input (for example, the search query [go]). Search results 908 are displayed in the search results section 906 and include one or more icons (for example, patient icons 822) associated with patients who are determined to be responding to the search query.
[00106] The example search interface of figures 9A and 9B is shown
53/81 specific user and site specific. In some implementations, this search interface may be user specific, but not site specific. For example, an agnostic site search interface can be displayed, can receive a search query, and can display patient icons representative of all patients in response to the search query and assigned to the user across all facilities that the user is associated.
[00107] According to the implementations of this exhibition, the user can select a patient icon (for example, a patient icon 822). In the amount predetermined to the user selection, a patient screen can be displayed. In some examples and in response to user selection of a patient icon, a request is provided for DMS 160 ’. In some instances, and in response to the request, the DMS 160 'accesses one or more patient indexes for identifying data sources, from which the patient data / information is to be retrieved for the particular patient. In some examples, the DMS 160 'retrieves patient data / information for the identified patient from a plurality of data sources, and provides instructions for the mobile device for displaying the patient data / information on a patient screen.
[00108] In the example provided above, a first EMR can be provided for a patient by an ambulance service that transported the patient to the hospital, a second EMR can be provided for the patient by the hospital, a third EMR can be provided for the patient through the rehabilitation center and a fourth EMR can be provided for the patient by a nursing company that is providing home nursing care for the patient. In addition, the patient can be readmitted to the hospital on an outpatient basis and can be connected to one or more
54/81 patient monitoring that generate physiological patient data based on a patient's physiological activity. According to implementations of the present exhibit, patient data / information from one or more of the first EMR, the second EMR, the third EMR and the fourth EMR, as well as real-time patient data can be provided for display to a healthcare provider (for example, a doctor attending to the patient) on a mobile device.
[00109] Continuing with the example above, the DMS 160 'can access a patient index that maps the patient to one or more data sources (for example, the first EMR, the second EMR, the third EMR, the fourth EMR and real-time patient data from monitoring device (s), from which the patient data / information is to be retrieved for display on the patient screen. In some examples, only a subset of data sources from one or more data sources is identified for data retrieval / patient information. For example, it can be determined that, for a currently selected patient view, patient data / information from the second and third EMRs is to be displayed on the patient screen. This is illustrated in the sample patient screens discussed in more detail below. In addition, it can be determined that the recovered patient data is to be processed for the provision of analytical data. Sample analytical data can include trend data displayed in graphs, as discussed by way of example below.
[00110] In some examples, patient screens can be model-based, for the definition of which patient data / information are to be displayed on a particular patient screen (for example, in implementations using the application platform of furniture 520 of figure 5). In some examples, a sub model
55/81 next to a patient screen can define which patient data / information are to be displayed in which portions of the patient screen. In some examples, a model underlying a patient screen can define analytical data that is to be displayed in portions of the patient screen. In some examples, a model may be provided as a standard model. In some examples, a custom model may include a standard model that has been modified by a user.
[00111] With reference now to figures 10A to 10C, sample patient screens will be discussed. Figure 10A describes an example patient screen 1000. In some examples, patient screen 1000 includes a header 1002, a menu 1003 and a display region 1005. In some examples, header 1002 includes summary patient information (for example, patient name, patient body mass index (BMI), patient gender, facility, status, and the like). In some examples, the display icons are provided to indicate patient data / information that is to be displayed in the display region 1005. In the example described, the display icons include a patient summary icon 1004, a summary icon detailed 1006 (“Recap”), a patient vital signs icon 1008, a real-time monitoring icon 1010 (“Live”), an electrocardiogram icon (ECG) 1012, a labs 1014, a 1016 drugs icon (“Meds”) (drugs) and a 1018 banknote icon. In some examples and as discussed in more detail here, a selection of an icon from menu 1003 alerts you to the data display / patient information in particular.
[00112] In the example in figure 10A, a detailed summary icon 1006 is selected, and one or more detailed summaries of patient data / information is provided in the display region 1005. In some
56/81 examples, the detailed summary icon 1006 is provided as a standard icon selection in response to the user selection of a particular patient icon (for example, a patient icon 822 in figure 8B). In some examples, the detailed summary screen 1006 is based on a model that defines display sub-regions to be provided in display region 1005, and the patient data / information and / or analytical data that are to be provided in each one of the display sub-regions.
[00113] In the example in figure 10A, the display subregions 1030, 1032, 034, 1036, 1038, 1040. For example, the display subregion 1030 displays general patient information (for example, patient identifier , age, sex, height, weight, BMI, admission date, diagnosis on admission, and attending physician on admission). Display sub-region 1032 displays information associated with the current illness / disease (for example, history of present illness (HPI), main complaint and problems). In some examples, the infrared provided in display sub-region 1032 may include textual information that is introduced by a healthcare provider (for example, a nurse, an attending physician) into a clinic information system. Display sub-region 1034 displays information associated with vital signs for the particular patient (for example, nursing vital signs, events, live). In the example described, nursing vital signs can include an HR value (for example, an HR range), a diastolic blood pressure value (BP-Dias) (for example, a range), an average blood pressure value (BP-Mean) (for example, a range), and a temperature value (Temp) (for example, a range). Display sub-region 1036 can display graphical trends for vital signs displayed in sub-region 1034. In the example described, “Nursing Vitals” are displayed in the display sub-region
57/81
1034. Consequently, the display sub-region displays graphical trends for these vital signs. Also, unique markers (for example, heart, triangle, square, circle, different colors) can be associated with vital signs in the 1034 display sub-region, and can be reflected in the graphic trends in the 1036 display sub-region. In this way, it is easily discerned which graphical trend corresponds to which vital sign.
[00114] In the example described, display sub-region 1038 displays a summary of laboratory results (“labs”) that have been determined to be abnormal (“Abnormal Labs”) (abnormal laboratories). In some examples, and as described in figure 10A, laboratory data can be displayed in tabular form based on date. In some examples, the displayed laboratory data may be color-coded (for example, blue indicates a decrease in value, red indicates an increase in value). In the example described, display sub-region 1040 displays active drugs (“Active Meds”) (for example, drugs that the patient currently prescribes and / or that are being administered to the patient (infusions)).
[00115] As mentioned above, patient screens can be provided based on a model. In some examples, the model is user specific. For example, in response to a user's selection of a particular patient, the DMS 160 ’determines the patient screen model to be used based on the user. In some examples, the specific user model defines what patient data / information is to be displayed on the resulting patient screen. Based on the definition provided in the model, the DMS 160 'can retrieve data from one or more corresponding data sources, and, if so defined, can process data for the provision of analytical data (e.g., graphical trends). The DMS 160 ’can provide
58/81 instructions for the mobile device to display the retrieved patient data / information and / or analytical data, as defined by the model.
[00116] Referring now to figure 10B, the detailed patient summary window 1050 can overlap the patient screen 1000. The detailed patient summary window 1050 can be displayed in response to a user selection of the patient icon. patient summary 1004. Sample patient data / information that can be displayed in the 1050 window can include 1052 allergies (for example, drug allergies, food allergies, environmental allergies), 1054 patient information (for example, identifier patient name, name (first, middle, last), BMI, sex, DOB, social security number (SSN), age, height, weight, diagnosis on admission, installation, status and the like), information associated with the disease / current illness (symptoms) (eg, HPI, major complaint and problems) 1056, and member of the Care Providers (care providers) 1058. Patient information can be provided as a static list ica, including multiple tabs per category. For example, symptoms 724 can be displayed as a text, divided under multiple tabs corresponding to the history of present disease (HPI), main complaints and problems. In some examples, a request is provided for DMS 160 'in response to a user selection of icon 1004, and DMS 160' retrieves patient data / information from appropriate data sources and provides instructions for the mobile device. display the 1050 detailed patient summary window.
[00117] With reference now to figure 10C, the user can provide a user entry for patient screen 1000 to change which patient data / information are to be displayed. In the example described, the user selected vital signs “Live” in the sub region of exi
59/81 bition 1034. In response to user input, real-time waveform data can be displayed in the display sub-region 1036 '. For example, in response to the “Live” user selection in display sub-region 1034, a request can be provided for DMS 160 ', which can identify one or more data sources that can provide the requested patient data (for example, example, based on a patient index). In this example, one or more data sources can include one or more patient monitoring devices that generate patient data in response to a patient's physiological activity. In some examples, patient data is provided for display as a waveform of real-time patient data, as discussed in US Patent No. ^Q 8,255,238, the exposure of which is expressly incorporated herein by reference in its entirety.
[00118] With reference now to figure 11A, a vital signs screen 1100 is described. The vital signs screen includes header 1002 and menu 1003. In some examples, vital signs screen 1100 is displayed in response to a user selection of vital signs icon 1008 (for example, from patient screen 1000 ). In some examples, the vital signs screen 1100 may display the patient data / information and / or analytical data associated with the patient's vital signs. In the example described, the vital signs screen 1100 provides a graphical display region 1102 and a tabular display region 1104. In some examples, data provided in display regions 1102, 1104 may include data retrieved from multiple data sources , as discussed here.
[00119] In the example described, display region 1102 displays graphical trends reflecting changes in data over time, and display region 1104 displays one or more tables including the underlying data values in the graphical trends displayed in display region 1104 Sample vital sign data includes HR,
60/81
BP (BP-Sys, BP-Dias, BP-Mean), SPO2%, RR, and body temperature. In some implementations, the vital signs screen 1100 includes multiple tabs corresponding to a plurality of categories, including nursing vital signs (as shown in figure 11 A), monitoring vital signs, and input-output (l & O) (as illustrated in figure 11B).
[00120] In the example above figure 11A, a plurality of graphical trends is provided in the display region 1102. In this example, graphical trends include a graph displaying trend views (for example, graph series) for all vital signs monitored, a graph showing trend visualizations (for example, graph series) for HR and SPO2% (eg, a first subset of monitored vital signs) and a graph showing trend visualizations (eg, graph series) for signals BP vital signs (BP-Sys, BP-Dias, BP-Mean) (for example, a second subset of monitored vital signs). As discussed above, display region 1104 displays one or more tables including the underlying values of the graphical trends displayed in display region 1104. In the example described, an “All Vitals” table is displayed and corresponds to the “All Vitais” trend graph. It is appreciated that, in the display region 1104, a first “Rates” table can be displayed corresponding to the “Rates” trend graph including BP vital signs (BP-Sys, BPDias, BP-Mean) (for example) example, the second subset of monitored vital signs). For example, a user input can be provided for display region 1104 for scroll induction (for example, up, down) for revealing additional tables.
[00121] In some examples, a legend is provided for each graph, the legend describing which vital signs are included in the respective graph, and a unique marker associated with each vital sign.
61/81
In some examples, charts are scrollable independently or collectively to reveal initial trend data (for example, scrolling to the right), or later trend data (for example, scrolling to the left). In the example in figure 11A, the table displayed in the display region 1104 includes data point values for vital signs displayed in the graphics in the display region 1102. In this way, the user can see the concrete data values in which the trend are based. Consequently, trend graphs allow quick recognition of vital trends, and allow the user to identify data points of interest, for retrieving the data underlying trend graphs from the table.
[00122] In some examples, a range can be changed to provide more detailed or more abstract trend graphs and tables. In the example in Figure 11A, an example interval includes an hour. Consequently, the trend graphs displayed in display region 1102 and the table displayed in display region 1104 are based on hourly increments. In some examples, a user input can be provided for the vital signs screen 1100 for changing the interval. For example, a user can click on a 1106 icon and a drop-down menu can be provided, from which the user can select a desired interval (for example, 1 minute, 15 minutes, half an hour, 12 hours, 24 hours. way, the user can review fine-grained or higher-level trend graphs and tables.
[00123] In some examples, the table is scrollable to reveal initial data values (for example, scrolling to the right), or later data values (for example, scrolling to the left). In some examples, the trend graph (s) and table (s) are collectively rolled. For example, scrolling a trend graph
62/81 results in a combined roll of the corresponding table. As another example, scrolling a table results in a combined scrolling of the corresponding trend graph. In this way, the data values underlying points on the trend graph remain synchronized with the trend graph. In some implementations, a scroll may be provided in response to user input. In some instances, a scroll in response to a user swipe action on a touch screen in a left-to-right direction to induce a scroll backward in time. As another example, a user can swipe the screen in a direction from left to right to induce scrolling forward in time.
[00124] Figure 11B describes another vital signs screen, an L&O 1100 'screen that can be displayed in response to a user selection from the L&O tab (for example, from the 1100 vital signs screen of figure 11A ). In figure 11B, the L&O screen 1100 'includes a graph display region 1110 and a table display region 1112. In some examples, the l & O screen 1100' in figure 11B describes the patient's admission and extraction of fluids and / or solids in both graphical form (shown in display region 1110) and tabular form (shown in display region 1112). In some examples, a range can be changed to provide more detailed or more abstract graphs and tables. In the example in figure 11B, an example range includes one day. Consequently, the bar graphs displayed in the display region 1110 and the table displayed in the display region 1112 are based on one-day increments. In some examples, a user input can be provided for the l & O 1100 'screen to change the interval. For example, a user can select a desired interval (for example, 1 hour, 12 hours, 1 week, 1 month). In this way, the user can review finer-grained or higher-level ten63 / 81 graphs and tables.
[00125] As mentioned above, with respect to patient screens, vital signs screens can be provided based on a model. In some embodiments, the model is user specific. For example, in response to the user's selection of the patient vital signs icon 1008, the DMS 160 ’requires the vital signs display model to be used based on the user. In some examples, the specific user model defines which graphs and / or tables are to be displayed on the resulting vital signs screen. Based on the definition provided in the model, the DMS 160 'can retrieve data from one or more corresponding data sources, and, if so defined, can process data for the provision of analytical data (e.g., graphical trends). The DMS 160 'can provide instructions for the mobile device to display the retrieved patient data / information and / or analytical data as defined by the model.
[00126] Figures 12A and 12B describe example 1200, 1202 monitoring screens, respectively. With particular reference to figure 12A, the monitoring screen 1200 can be displayed in response to a user selection of the real-time monitoring icon 1010. In some examples, the patient's physiological parameters can be monitored by one or more monitoring devices. monitoring, which respond to a patient's physiological activity and generate patient physiological data based on this (see figures 1 and 2). As provided in US Patent No. ^Q 8,255,238 referenced above, physiological patient data can be transmitted to the mobile device for the provision of real-time monitoring of patient physiological data.
[00127] In some examples, the monitoring screen 1200 includes a real-time waveform display region 1210 and real-time textual display regions 1212, 1214. In the example des
64/81 written, the display region 1212 includes the display subregions 1216, 1218, 1220, 1222, each of which is associated with a respective physiological parameter of the patient being monitored. In the example described, display region 1214 includes display subregions 1224, 1226, 1228, 1230, 1232, 1234, each of which is associated with a respective physiological parameter of the patient being monitored. In some examples, display sub-regions 1224, 1226, 1228, 1230, 1232, 1234 in display region 1214 reveal the addition of display sub-regions and associated patient physiological parameters being monitored.
[00128] In some examples, monitoring screen 1202 displays discrete events associated with the monitored patient's physiological parameters. In some examples, monitoring screen 1202 displays patient data and / or waveforms associated with one or more events. In some instances, an event can be triggered in response to monitored patient data falling below or exceeding a predefined threshold (for example, an alarm). In some instances, an event may be triggered in response to an acknowledgment of a pattern (for example, one or more sub-events occurring within a predetermined timeout of another).
[00129] In the example in figure 12B, monitoring screen 1202 includes display regions 1250, 1252, 1254, 1256, 1258. In some examples, display regions 1250, 1252, 1254, 1256, 1258 are scrollable (for example vertically) to reveal additional display regions. In some examples, each display region 1250, 1252, 1254, 1256, 1258 is associated with a respective time interval. In the example described, display region 1250 is associated with events that occurred in the past hour, display region 1252 is associated with events that occurred 1 to 2 hours ago, display region 1254 is associated with events that occurred from 2 to 3 hours
65/81 ago, display region 1256 is associated with events that occurred 3 to 4 hours ago, display region 1258 is associated with events that occurred 4 to 5 hours ago.
[00130] In some examples, event summaries are provided and may include waveform data and / or textual data associated with the respective event. In the example in figure 12B, event summaries 1260a through 12060Í are displayed. In some examples, event summaries may include an indication of priority (for example, high (H), medium (M), low (L)). In some examples, priority may be provided based on the severity of the event and / or the type of event. For example, if a monitored patient's physiological parameter exceeds a limit by a first quantity, a low priority event can be triggered, if the monitored patient's physiological parameter exceeds a limit by a quantity (greater than the first quantity), a medium priority event may be triggered, and if the monitored patient's physiological parameter exceeds the limit by a third quantity (greater than the second quantity), a high priority event may be triggered. In some instances, a patient's physiological parameter may be of particular importance. Consequently, if the patient's physiological parameter exceeds a limit, regardless of how much, a high priority event will be triggered. In some instances, a patient's physiological parameter may be less important. Consequently, if the patient's physiological parameter exceeds a threshold, regardless of how much, a low or medium priority event will be triggered.
[00131] Each event summary 1260a through 1260i provides relevant patient data and waveform data associated with the respective event. In some examples, and in each discrete event summary 1260a to 1260i, the user can scroll the waveform data, for
66/81 example, forward or backward in time to reveal waveform data before or after the event.
[00132] According to the implementations of the present exhibition, the monitoring screens can be provided based on the respective models. In some examples, the model is user specific. For example, in response to a selection of the 1010 real-time monitoring icon by the user, the DMS 160 ’determines the model of the real-time monitoring screen that is to be used based on the user. In some examples, the specific user model defines which waveforms and / or textual patient data are to be displayed on the resulting monitoring screen. Based on the definition provided in the model, the DMS 160 'can retrieve the data from one or more corresponding data sources. The DMS 160 'can provide instructions for the mobile device to display the recovered data, as defined by the model. In the case of real-time waveforms, the DMS 160 'can continuously provide real-time data from a data source (for example, a monitoring device) for display as a waveform on the monitoring screen.
[00133] Figure 13 describes an example ECG 1300 display graphically representing an ECG on the display of a mobile device. In some examples, the ECG screen is displayed in response to a user selection of the 1012 ECG icon. The example ECG discussed here corresponds to a 12-wire ECG. The implementations of this exhibition are applicable to any appropriate type of ECG. The ECG 1300 screen provides graphical information regarding data collected from a patient monitoring device. In particular, the ECG 1300 screen provides cardiology information relating to the data collected from an ECG monitoring device attached to a patient.
67/81 [00134] The ECG screen 1300 includes a display region 1302 and a display region 1304. In the example described, display region 1302 provides a grid of trace windows from ECG 1310a to 13101 (for example, 4 columns by 3 rows, the first column including wires I, II and III, the second column including wires aVR, aVL and aVF, and the last two columns including wires V ^ Ve). Each trace window 1310a to 13101 includes a respective voltage trace 1305a to 13051 corresponding to the respective wire for a period of time. In some examples, trace windows 1310a to 13101 can be used to zoom in and out and to scroll along segments of the respective voltage traces 1305a to 13051.
[00135] Display region 1304 includes expanded dash windows, each dash window expanded corresponding to a dash window provided in display region 1302. In the example in figure 13, expanded dash windows 1312a, 1312b are displayed and correspond to the dash windows 1310a, 1310b, respectively, of the display region 1302. In some instances, the expanded dash windows may be rolled up / down in the display region 1304 to reveal additional expanded dash windows. For example, expanded dash windows not shown (e.g., expanded dash windows 1312c through 11121), or partially displayed expanded dash windows (e.g., expanded dash window 1312b) can be scrolled to full view, while expanded dash windows (for example, expanded dash windows 1312a, 1312b) can be rolled out of view.
[00136] The display region 1304 can display the expanded trace windows 1312a to 13121 having respective voltage strokes 1313a to 11131, each voltage trace 1313a to 13131 corresponding to the voltage strokes 1305a to 13051. The voltage strokes 1313a to 13131 are provided, each, as full features for a period of
68/81 time in particular, graphing the ECG data collected for the particular time period. In some examples, the user defines a desired time period for ECG data viscosity by zooming in to zoom in / out and / or scroll along one of the voltage traces 1305a to 13051 in trace windows 1310a to 13101. Thus whereby trace display windows 1310a to 13101 respectively display segments of voltage traces 1305a to 13051, the segments corresponding to respective segments of voltage traces 1313a to 13131 shown in expanded trace windows 1312a to 13121. That is, each window line 1310a to 13101 can display a full line or a voltage line with zoom to approximate 1305a to 13051 corresponding to a voltage line 1313a to 13131. In some instances, voltage lines 1305a to 13051 are synchronized with each other such that a scroll and / or zoom of a trace of voltage 1305a to 13051 in a trace window 1310a to 13101 results in an equivalent scroll and / or zoom in each of the other traffic windows steel 1310a to 13101. Consequently, each trace window 1310a to 13101 displays its respective voltage trace 1305a to 13051 for the same period of time.
[00137] With continued reference to figure 13, a beveled scroll bar 1320 can be provided in each of the trace windows 1312a to 13121. The beveled scroll bar 1320 provides a display area 1322 having a width w. The display area 1322 displays a portion of the voltage trace 1313a to 13131 corresponding to the portion of the voltage trace 1305a to 13051 displayed in trace display windows 1310a to 13101. Therefore, the width w generally corresponds to the time period of the dashes voltage 1305a to 13051. In the example in figure 13, width w corresponds to the time period between time t ₃ and ₄ . The 1320 beveled scroll bars provide a graphic indicator that allows
69/81 a user quickly discerns which portion of the voltage traces 1313a to 13131 corresponds to the voltage traces 1305a to 13051.
[00138] Further details of example ECG displays are provided in International Order N ^Q PCT / US2012 / 021677, which claims the benefit of Provisional Order US 61 / 433,824, the exposures of which are expressly incorporated herein by reference in their entirety.
[00139] Figures 14A to 14C describe example implementations of a lab screen ("labs") 1400 that displays laboratory data associated with a patient. In some examples, laboratory screen 1400 is displayed in response to a user selection of laboratory icon 1014. Laboratory data that can be displayed includes basic metabolic panel (BMP) (eg, glucose, potassium, CO ₂ , chloride , blood nitrogen urea (BUN), creatinine and the like), venous blood gases, lipids, arterial blood gases (e.g., pH, pCO2, PaCO2, pO2, PaO2, HCO3, tC03, and the like), glucose panels, electrolytes , hypothyroid, renal function and liver function, among others.
[00140] In the examples described, laboratory screen 1400 includes multiple display regions 1402, 1404, each display region corresponding to a respective laboratory panel. For example, display region 1402 displays BMP, and display region 1404 displays arterial blood gases. In some examples, the display regions are scrollable (for example, up / down) to reveal additional display regions and corresponding lab panels. In the example described, lab data on a lab panel is displayed based on an associated time / date. In some example, the time / date corresponds to a time / date when a sample (for example, blood sample, urine sample) was taken from the patient.
70/81 [00141] Also, and in a display region, laboratory results can be scrolled (for example, up and down or left and right) to reveal additional laboratory results. For example, display region 1404 of figure 14A provides partial laboratory results for HCO3. In display region 1404, the user can scroll the laboratory results to air interface control to reveal the complete data values for the HCO3 laboratory results, as well as additional data results (for example, tC03 that resides outside the display region 1404 in figure 14A). In some examples, laboratory results in a display region can be scrolled left / right to reveal later / earlier values in time / date.
[00142] According to the implementations of this exhibition, data values can be color coded and / or annotated in the display regions. In some examples, a data value is outside a normal range (for example, as determined by the laboratory providing the laboratory results) can be indicated based on color and / or annotation. In the example described, a value that the laboratory determined to be above the normal range includes an upward pointing arrow and a red color. In the example described, a value that the lab determined to be below the normal range includes an arrow pointing down, and is colored blue. In some examples, a data value severely above or below a normal range (for example, as determined by the laboratory) can be indicated using multiple annotations (for example, double arrows). In some examples, the laboratory may determine that a data value is deserving of a textual note, and, when this happens, these notable data values can be indicated based on color and / or annotation. In the example described, a va71 / 81 data value can be indicated visually with a warning annotation (for example, an exclamation point in a triangle) and is colored orange. In some examples, the laboratory may determine that a data value should be indicated visually with a warning annotation, and may provide a textual note that can be displayed to the user (for example, in response to a user input for the value data).
[00143] In accordance with the implementations of this exhibition, laboratory screens can be provided based on the respective models. In some examples, the model is user specific. For example, in response to a selection of the lab icon 1014 by the user, the DMS 160 ’determines that the lab model is to be used based on the user. In some examples, the specific user model defines what lab data is to be displayed on the resulting lab screen. Based on the definition provided in the model, the DMS 160 'can retrieve laboratory data from one or more corresponding data sources. The DMS 160 'can provide instructions for the mobile device to display the recovered data, as defined by the model. In some examples, the DMS 160 'can process the data for data identification, for which indications and / or annotations must be provided. In these examples, instructions provided for the mobile device may include instructions for indicating (for example, color coding) and / or annotation (for example, up arrow (s), down arrow (s), warning symbol) respective data values.
[00144] In some implementations, and as described in the example in figure 14B, the user can interact with displayed data values to retrieve more detailed information. In the example in figures 14A to 14B, the user can provide a user entry (for example, a ring) for data value 1410. In res
72/81 set to user input, a window 1416 can be displayed. In some examples, window 1416 provides more detailed information about the laboratory data. In the example described, window 1416 provides the name of the lab result 1418, a collection information (for example, panel name, sample source, device name, order provider and collection date and time) 1420, value of result 1422, comments 1424 and contact data 1426 (for example, the lab that generated the lab result). In some implementations, the user can click on the 1424 comments section to edit, add and / or delete comment data.
[00145] According to implementations of the present exhibition, a laboratory data window (for example, window 1416) can be provided based on the respective models. In some examples, the model is user specific. For example, in response to a selection of the particular data value 1410 displayed on the lab screen 1400 by the user, a request is sent to DMS 160 ’, and DMS 160’ determines which window model is to be used. The DMS 160 ’can retrieve the more detailed laboratory data that is to be displayed in the window from one or more corresponding data sources. The DMS 160 'can provide instructions for the mobile device to display the window including the retrieved data.
[00146] In some examples, the user can customize which laboratory data is displayed on the laboratory screen 1400. In some examples and in response to a user selection of a menu icon 1412, a drop-down menu 1450 is displayed (see the figure 14C). In some examples, the drop-down menu provides a list of laboratory data that can be displayed on the display screen 1400. In some examples, and as described in figure 14C, the user can check the check boxes associated with laboratory data
73/81 that the user would like to display on the 1400 lab screen. In some examples, and in response to the user selection (for example, when the user clicks the “Done” button), a message is sent to the DMS 160 'indicating the laboratory data that is to be displayed on the laboratory screen. In response to the message, the DMS 160 'can provide laboratory data and instructions for displaying laboratory data on the 1400 laboratory screen.
[00147] Figures 15A and 15B describe an example 1500 drug screen ("Meds"). As discussed in more detail here, the 1500 drug screen describes active drugs and / or non-active drugs. In some examples, the 1500 drugs screen is displayed in response to a user selection of the 1016 drugs icon.
[00148] With particular reference to figure 15A, the drug screen 1500 displays active drugs that have been ordered to be administered to the particular patient. In some examples, drugs can be grouped and displayed based on an administration category. Sample categories can include drugs that are to be administered by continuous infusion, continuous infusion, drugs that are to be administered on a “scheduled” schedule, and drugs that are to be administered pro re nata (“PRN”) (as needed based on the circumstances). In the example in figure 15A, display regions 1504, 1506, 1508 are provided, each display region corresponding to a respective category of drug orders, and displaying drugs for which there is an active order for the patient for each category. In some examples, drug information is provided for each drug. Drug information can include a drug name, a drug class (e.g., a therapeutic class,
74/81 such as for pain relief, anti-swelling, blood thinning and the like), medication order details (eg, dosage amounts, dosage concentrations, dosing intervals, and the like), start date ( for example, time / date when drug administration started), last dosage rate and time (for example, for continuous infusion drugs) and last time / date of administration (for example, for scheduled and / or PRN drugs) .
[00149] In the example in figure 15A, the drug screen 1500 displays all active drugs for the patient. In some instances, the 1500 drug screen is scrollable (for example, up / down) to reveal additional drugs. In some examples, the active drug displayed on the 1500 drug screen can be filtered. For example, and in response to a user input on a 1520 icon, a drop-down menu (not shown) can be displayed to allow the user to filter active drugs to show less than all.
[00150] In figure 15B, the drug screen 1500 displays similar information with reference to a drug, as provided in figure 15A. The drugs provided in figure 15B, however, are not active drugs. In some instances, non-active medications may include medications for which the order has been completed, suspended, discontinued and / or canceled. In the drug screen in figure 15B, non-active drugs can be grouped for display based on status (for example, completed, suspended, discontinued and / or canceled).
[00151] As discussed in a similar way above, the medication screen can be provided based on a model. In some examples, the model is user specific and / or patient specific. For example, in response to a selection of the medication icon
75/81 tos 1016 by the user, the DMS 160 ’determines the drug screen model to be used based on the user and / or the particular patient. In some examples, the user-specific and / or patient-specific model defines which drugs and / or administration categories are to be displayed on the resulting drug screen. Based on the definition provided in the model, the DMS 160 'can retrieve the data from one or more corresponding data sources. In some examples, multiple data sources can be accessed, each data source corresponding to a facility that has or is administering medication to the patient. The DMS 160 ’can provide instructions for the mobile device for displaying drug / information data, as defined by the model. [00152] Figures 16A and 16B describe an example 1600 document screen. In some examples, the 1600 document screen may be displayed in response to a user selection from the 1018 notes icon. In some examples, the documents screen 1600 provides a display region 1602 and a display region 1604. In some examples, the display region 1602 provides a menu of documents that are available for viewing on the mobile device. In some examples, the menu provides a document type and / or a document title, as well as a date / time associated with the document (for example, the date / time the document was prepared, stored in a respective data source , last edited). Sample documents can include a report of 3 operations, a patient's medical history, a discharge summary, a medication profile and a coding summary. It is appreciated, however, that any appropriate document can be displayed on the mobile device. In some implementations, documents can include multiple text, digital image and / or mixed content files. Sample document files can include PDF, RTF, TXT,
76/81
DOC, TIFF, BMP, JPEG, GIF and other appropriate document formats.
[00153] In some examples, a document is selected from the menu (in display region 1602) and, in response, the document is displayed in display region 1604. In the example in figure 16A, the document “3-Operative Report ”Is selected from the menu, and the corresponding document is displayed in the display region 1604. In the example in figure 16B, the document“ Discharge Summary ”is selected from the menu, and the corresponding document is displayed in the display region 1604 In some instances, the document may be scrolled vertically and / or horizontally, to reveal other parts of the document that are not visible in the 1605 display region. In some instances, scrolling the document may be provided in response to an action of user finger swipe on the touch screen. In some implementations, the user can zoom in / out and / or change the font size of the text in the displayed document. In some implementations, the user can edit any or some of the selected documents for viewing.
[00154] In some implementations, the display of documents can be influenced based on a rotation of the mobile device. In some instances, a rotation of the mobile device from landscape to portrait may cause the menu (display region 1602) to disappear and the document to appear in full screen. In some instances, a rotation of the mobile device back to landscape may result in the menu (the display region 1602) reappearing and the document being partially displayed. In some implementations, screen display behavior discussed here (for example, in figures 7 to 16B) can be similarly influenced by a rotation of the mobile device between landscape and portrait views.
[00155] As discussed in a similar way, the documents screen
77/81 can be provided based on a model. In some examples, the model is user specific and / or patient specific. For example, in response to a selection of the notes icon 1018 by the user, a request is provided for the DMS 160 ', and the DMS 160' determines the document screen template to be used based on the user and / or the patient in particular. In some examples, the user-specific and / or patient-specific model defines which documents are to be displayed on the resulting document screen. In some examples, documents may include all documents that are available to the particular patient from one or more data sources. The DMS 160 'can retrieve document data (for example, document files) from one or more corresponding data sources. In some examples, multiple data sources can be accessed, each data source corresponding to a facility that generated a document associated with the patient.
[00156] In some examples, the DMS 160 'can provide instructions for the mobile device to display the menu defined by the model, including a summary of each available document (for example, a type of document and / or title). In some examples, and in response to a user selection of a document from the menu (For example, in the display region 1602), a requisition can be provided for DMS 160 ’, requesting the particular document. In response, the DMS 160 ’can retrieve the document file from a corresponding data source, and can provide the document file to the mobile device. The mobile device can process the document file for the provision of the document for display (for example, in display region 1604).
[00157] Figure 17 describes an example 1700 process that can be performed according to the implementations of this
78/81 exhibition. In some examples, the 1700 sample process can be provided in one or more computer executable programs that can be executed using one or more computing devices (for example, the mobile device 102 and / or the DMS 160, 160 ' ).
[00158] A user request is received (1702). For example, DMS 301 of figure 3 can receive a user request from the mobile device 102. It is determined whether at least a portion of the user request can be fulfilled in the repository mode (1704). For example, it can be determined that at least some patient data and / or patient information being requested can be provided from a local data store (cache). If it is determined that at least a portion of the user request can be served in the repository mode, the cache data will be retrieved (1706) (for example, by the data cache module 314 in figure 3). If it is determined that at least a portion of the user request cannot be fulfilled in the repository mode, it will be determined whether the request, or at least a portion of it, can be served in federated mode (1708). If it is determined that the request, or at least a portion of it, cannot be answered in federated mode, a response will be provided to the mobile device (1710). In some examples, the answer is based only on cached data that has been retrieved (for example, the restored mode).
[00159] If it is determined that the request or at least a portion of it can be served in federated mode, one or more data sources, from which patient data and / or patient information are to be retrieved are identified ( 1712). One or more requests are transmitted (1714). For example, the adapter module 316 in figure 3 can route requests to power sources.
79/81 appropriate data to meet the user request. One or more responses are received (1716). For example, the adapter module receives responses from each of the data sources, from which patient data and / or patient information were requested. An answer is provided for the mobile device (1718). For example, responses from data sources can be processed by DMS 301, as discussed above, to provide a response to the user request for the mobile device 102. In some examples, the response may include data from patient and / or patient information provided from federated mode only, or provided from repository mode and federated mode.
[00160] The implementations of the present exhibition can be provided using digital electronic circuits, or in computer hardware, firmware, software or in combinations thereof. In some examples, implementations can be provided in one or more computer program products, for example, a computer program that is tangibly implemented in a storage device that can be read on a machine, for execution by or for control of the operation data processing apparatus, and / or a programmable processor, a computer or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and mesh framework can be employed in any form, including as an independent program or as a module, component, subroutine, or another unit suitable for use in a computing environment. A computer program can be employed to run on one computer or on multiple computers at one location or distributed across multiple locations and interconnected over a communication network.
80/81
A computer program may include modules and / or segments of code to execute one or more of the features, aspects and / or implementations provided here.
[00161] The operations according to the implementations of the present exhibition can be performed by one or more programmable processors executing a computer program product to execute functions by the data entry and output generation operation. As an example, a computer program product may include modules and / or segments of code corresponding to each of the method steps, aspects and / or resources provided here. The method steps can also be performed by and the devices in the present exhibition can be implemented as a special purpose logic circuit, for example, an FPGA (field programmable door arrangement) or an ASIC (application specific integrated circuit).
[00162] The processors suitable for the execution of a computer program include, for example, microprocessors of general and special purpose, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from either a read-only memory or a random access memory or both. The elements of a computer can include a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer can also include or be operatively coupled to receive data from or transfer data to or both one or more mass storage devices for data storage, for example, magnetic, magnetic-optical disks or optical disks. Information carriers suitable for carrying out computer program instructions and data include all forms of memory
81/81 non-volatile, including, for example, semiconductor memory devices, for example, EPROM, EEPROM and flash memory devices; magnetic disks, such as internal hard drives and removable disks; magnetic-optical disks; and CD-ROM and DVD-ROM discs. The processor and memory can be supplemented by or incorporated into a special purpose logic circuit.
[00163] The present exhibition can be implemented in a system that includes, but is not limited to the example systems described here, which include a back-end component, for example, as a data server, or that includes a component middleware, for example, an application server, or that includes a front-end component, for example, a client device, such as the mobile device 102, having a graphical user interface or a web browser through which a user can interact with an implementation of the invention, or any combination of these back-end, middleware or front-end components. The system components can be interconnected by any form or means of digital data communication, for example, a communication network.
[00164] Several implementations have been described. Nevertheless, it will be understood that several modifications can be made, without deviating from the spirit and scope of the exhibition. For example, the steps of the present exhibition can be carried out in a different order and still obtain desirable results. Therefore, other implementations are in the scope of the following claims.

权利要求:
Claims (19)
[1]
1. Method implemented on a computer for integration, unification and display of patient data through continuous health care, the method being executed using at least one processor (124) and characterized by the fact that it comprises the steps of:
receiving, via at least one processor (124), a user request, the user request being received in response to a user input on a mobile device (102, 102 ’, 102”);
determining that the user request is associated with patient data and / or patient information stored in a plurality of data stores (142) associated with a plurality of installation systems (108, 110, 302, 304), each store data (142) in the plurality of data storage (142) being associated with a respective installation system (108, 110, 302, 304);
transmit a plurality of requests, each request being directed to a respective installation system (108, 110, 302, 304);
receiving a plurality of responses, each response responding to a respective request from the plurality of requests; and transmit a response to the mobile device (102, 102 ’, 102”), the response responding to the user request.
[2]
2. Method, according to claim 1, characterized by the fact that determining that the user request is associated with patient data and / or patient information stored in a plurality of data stores (142), comprises access to an installed patient index, based on a patient identifier for determining a plurality of
Petition 870160024336, of 05/31/2016, p. 5/14
2/6 installation systems (108, 110, 302, 304), the patient identifier being included in the request.
[3]
3. Method, according to claim 1, characterized by the fact that it still comprises the identification of installation systems (108, 110, 302, 304) included in the plurality of installation systems (108, 110, 302, 304) with based on a provider index with installation, the provider index with installation mapping the user of the mobile device (102, 102 ', 102 ”) to installation systems (108, 110, 302, 304) from the plurality of installation systems ( 108, 110, 302, 304).
[4]
4. Method, according to claim 3, characterized by the fact that the step of identifying installation systems (108, 110, 302, 304) is performed based on a user identifier, the user identifier being provided in the request user.
[5]
5. Method, according to claim 1, characterized by the fact that each request in the plurality of requests comprises user credential data associated with the user of the mobile device (102, 102 ’, 102”).
[6]
6. Method, according to claim 5, characterized by the fact that it still comprises the recovery of user credential data from a provider index with installation, the provider index with installation mapping the user of the mobile device (102 , 102 ', 102 ”) for installation systems (108, 110, 302, 304) of the plurality of installation systems (108, 110, 302, 304).
[7]
7. Method, according to claim 1, characterized by the fact that it still comprises:
analyze the user request for determining patient data and / or patient information that meets the user request; and generate a thread based on patient data
Petition 870160024336, of 05/31/2016, p. 6/14
3/6 and / or patient information, the chain comprising a set of tasks that include one or more tasks performed to meet the user request, in which the transmission of the plurality of requests is included in the set of tasks.
[8]
8. Method, according to claim 1, characterized by the fact that it still comprises:
processing patient data and / or recovered patient information, patient data and / or recovered patient information being included in the plurality of responses; and generating the response that is to be provided for the mobile device (102, 102 ’, 102”).
[9]
9. Method according to claim 8, characterized by the fact that processing the patient data and / or recovered patient information comprises at least one of the generation of additional data based on the patient data, formatting the patient data retrieved and / or patient data, and conditioning patient data and / or patient information.
[10]
10. Method, according to claim 9, characterized by the fact that it still comprises the conditioning of additional data.
[11]
11. Method according to claim 9, characterized in that the additional data comprises data that can be processed by the mobile device (102, 102 ’, 102") for the generation of at least one data visualization.
[12]
12. Method, according to claim 9, characterized by the fact that conditioning the patient data and / or patient information comprises at least one among data conversion based on a transmission protocol, data formatting for optimal display in the mobile device (102, 102 ', 102 ”), and data packaging for transmission to the mobile device (102, 102', 102”).
Petition 870160024336, of 05/31/2016, p. 7/14
4/6
[13]
13. Method, according to claim 1, characterized by the fact that it still comprises the determination that the user request is associated with a portion of patient data and / or patient information stored in a cache data store ( 142), the response to the mobile device (102, 102 ', 102 ") being provided based on the portion of patient data and / or patient information.
[14]
14. Method, according to claim 1, characterized by the fact that the user request comprises a user identifier and a patient identifier, the user identifier and the patient identifier having cross-reference to at least one index for identification installation systems (108, 110, 302, 304) included in the plurality of installation systems (108, 110, 302, 304).
[15]
15. Method, according to claim 1, characterized by the fact that it still comprises user authentication of the mobile device (102, 102 ’, 102”).
[16]
16. Method, according to claim 1, characterized by the fact that it still comprises validation of the user request.
[17]
17. Method, according to claim 1, characterized by the fact that the response comprises instructions, the instructions being executable by the mobile device (102, 102 ', 102 ”) for displaying patient data and / or patient information in an integrated view on the mobile device (102, 102 ', 102 ”).
[18]
18. Storage device (142) that can be read on a computer, coupled to at least one processor (124) and having instructions stored on it, which, when executed by at least one processor (124), make the at least a processor (124) performs operations for integration, unification and display
Petition 870160024336, of 05/31/2016, p. 8/14
5/6 tion of patient data through continuous health care, characterized by the fact that the operations comprise:
receiving a user request, the user request being received in response to a user input on a mobile device (102, 102 ’, 102”);
determining that the user request is associated with patient data and / or patient information stored in a plurality of data stores (142) associated with a plurality of installation systems (108, 110, 302, 304), each store data (142) in the plurality of data storage (142) being associated with a respective installation system (108, 110, 302, 304);
transmit a plurality of requests, each request being directed to a respective installation system (108, 110, 302, 304);
receiving a plurality of responses, each response responding to a respective request from the plurality of requests; and transmit a response to the mobile device (102, 102 ’, 102”), the response responding to the user request.
[19]
19. System (100, 100 ', 300) for integration, unification and display of patient data through continuous health care, the system (100, 100', 300) comprising:
at least one processor (124); and a storage medium (142) that can be read on a computer in communication with at least one processor (124) and having instructions stored on it, which, when executed by at least one processor (124), make the at least a processor (124) performs operations to provide a user of a mobile device (102, 102 ', 102 ”) to access patient information and patient physiological data, characterized by the fact
Petition 870160024336, of 05/31/2016, p. 9/14
6/6 that operations comprise:
receiving a user request, the user request being received in response to a user input on the mobile device (102, 102 ’, 102”);
determining that the user request is associated with patient data and / or patient information stored in a plurality of data stores (142) associated with a plurality of installation systems (108, 110, 302, 304), each store data (142) in the plurality of data storage (142) being associated with a respective installation system (108, 110, 302, 304);
transmit a plurality of requests, each request being directed to a respective installation system (108, 110, 302, 304);
receiving a plurality of responses, each response responding to a respective request from the plurality of requests; and transmit a response to the mobile device (102, 102 ’, 102”), the response responding to the user request.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112015021229A2|2020-03-10|SYSTEM, METHOD AND STORAGE DEVICE FOR INTEGRATION, UNIFICATION AND DISPLAY OF PATIENT DATA THROUGH CONTINUOUS HEALTH CARE

---

US10402782B2|2019-09-03|Systems and methods for and displaying patient data

---

US10042979B2|2018-08-07|Systems and methods for integrating, unifying and displaying patient data across healthcare continua

---

US9524569B2|2016-12-20|Systems and methods for displaying patient data

---

US20140249855A1|2014-09-04|Systems And Methods For Integrating, Unifying And Displaying Patient Data Across Healthcare Continua

---

US10217527B2|2019-02-26|Systems and methods for integrating, unifying and displaying patient data across healthcare continua

---

AU2013249417B2|2018-01-18|Systems and methods for displaying patient data

---

US10922775B2|2021-02-16|Systems and methods for and displaying patient data

---

US10068057B2|2018-09-04|Systems and methods for integrating, unifying and displaying patient data across healthcare continua

---

US10460409B2|2019-10-29|Systems and methods for and displaying patient data

---

JP2015521308A5|2018-08-30|

---

US9996667B2|2018-06-12|Systems and methods for displaying patient data

同族专利:

---

公开号 | 公开日

---

AP2015008727A0|2015-09-30|

---

EP2962267A4|2016-09-07|

---

US20150088549A1|2015-03-26|

---

AU2020200196A1|2020-02-06|

---

CN105190681B|2020-09-29|

---

EP2962267A1|2016-01-06|

---

US20140249854A1|2014-09-04|

---

AU2014223470A1|2015-09-24|

---

CN105190681A|2015-12-23|

---

CA2903378A1|2014-09-04|

---

WO2014134293A1|2014-09-04|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5848241A|1996-01-11|1998-12-08|Openframe Corporation Ltd.|Resource sharing facility functions as a controller for secondary storage device and is accessible to all computers via inter system links|

---

US8255238B2|2005-01-03|2012-08-28|Airstrip Ip Holdings, Llc|System and method for real time viewing of critical patient data on mobile devices|

---

US8781532B2|2005-09-19|2014-07-15|Google Inc.|Customized data retrieval applications for mobile devices providing interpretation of markup language data|

---

US20090248437A1|2008-03-27|2009-10-01|General Electric Company|Systems and methods utilizing nfc technology to implement an on-demand portable medical record|

---

JP4772078B2|2008-04-08|2011-09-14|シャープ株式会社|Image forming apparatus and image forming apparatus control method|

---

US20130304512A1|2008-08-05|2013-11-14|Net.Orange, Inc.|System and method for sharing data in a clinical network environment|

---

US20130304496A1|2008-08-05|2013-11-14|Net.Orange, Inc.|System and method for optimizing clinical flow and operational efficiencies in anetwork environment|

---

US20130166317A1|2008-08-05|2013-06-27|Net.Orange, Inc.|System and method for visualizing patient treatment measures in a network environment|

---

EP2246798A1|2009-04-30|2010-11-03|TomTec Imaging Systems GmbH|Method and system for managing and displaying medical data|

---

US20110054936A1|2009-09-03|2011-03-03|Cerner Innovation, Inc.|Patient interactive healing environment|

---

US8832853B2|2009-12-07|2014-09-09|Dst Technologies, Inc.|Managed virtual point to point communication service having verified directory, secure transmission and controlled delivery|

---

US10956867B2|2010-03-31|2021-03-23|Airstrip Ip Holdings, Llc|Multi-factor authentication for remote access of patient data|

---

US9378485B2|2010-12-30|2016-06-28|General Electric Company|Systems and methods for applying geolocation to workflows using mobile medical clients|

---

US9495511B2|2011-03-01|2016-11-15|Covidien Lp|Remote monitoring systems and methods for medical devices|

---

US20120296672A1|2011-05-20|2012-11-22|Matthew Jere Bates|System and method for managing mobile hie information|

---

US20130086201A1|2011-09-29|2013-04-04|Computer Sciences Corporation|Mobile Patient Information System|

---

CA2861333C|2012-01-19|2017-12-05|Nike Innovate C.V.|Multi-activity platform and interface|

---

US9524569B2|2012-04-16|2016-12-20|Airstrip Ip Holdings, Llc|Systems and methods for displaying patient data|

---

EP2838422B1|2012-04-16|2018-11-14|AirStrip IP Holdings, LLC|Systems and methods for displaying patient data including physiological waveform with calipers|

---

US20140095207A1|2012-09-28|2014-04-03|Allen Technologies, Inc.|Systems and methods for displaying patient information on a mobile system|

---

US20140122119A1|2012-10-25|2014-05-01|Echostar Technologies, Llc|Medical data storage and retrieval|

---

WO2014134572A1|2013-02-28|2014-09-04|Matthew Barrett|Mobile communication and workflow managment system|US10217527B2|2013-03-01|2019-02-26|Airstrip Ip Holdings, Llc|Systems and methods for integrating, unifying and displaying patient data across healthcare continua|

---

US10042979B2|2013-03-01|2018-08-07|Airstrip Ip Holdings, Llc|Systems and methods for integrating, unifying and displaying patient data across healthcare continua|

---

US10068057B2|2013-03-01|2018-09-04|Airstrip Ip Holdings, Llc|Systems and methods for integrating, unifying and displaying patient data across healthcare continua|

---

US10460409B2|2013-03-13|2019-10-29|Airstrip Ip Holdings, Llc|Systems and methods for and displaying patient data|

---

US9996667B2|2013-03-14|2018-06-12|Airstrip Ip Holdings, Llc|Systems and methods for displaying patient data|

---

US10262382B2|2013-03-15|2019-04-16|Airstrip Ip Holdings, Llc|Systems and methods for and displaying patient data|

---

US9665264B1|2013-07-24|2017-05-30|Draeger Medical Systems, Inc.|Medical data display system graphical user interface|

---

US9257097B2|2013-12-23|2016-02-09|Qualcomm Incorporated|Remote rendering for efficient use of wireless bandwidth for wireless docking|

---

USD871426S1|2014-09-02|2019-12-31|Samsung Electronics Co., Ltd.|Display screen or portion thereof with graphical user interface|

---

US11232855B2|2014-09-23|2022-01-25|Airstrip Ip Holdings, Llc|Near-real-time transmission of serial patient data to third-party systems|

---

US10354051B2|2015-02-09|2019-07-16|Forge Laboratories, Llc|Computer assisted patient navigation and information systems and methods|

---

US10489554B2|2015-02-09|2019-11-26|Forge Laboratories, Llc|Computer assisted patient navigation and information systems and methods|

---

US10257277B2|2015-08-11|2019-04-09|Vocera Communications, Inc.|Automatic updating of care team assignments in electronic health record systems based on data from voice communication systems|

---

AU2016304884B2|2015-08-11|2021-01-28|Masimo Corporation|Medical monitoring analysis and replay including indicia responsive to light attenuated by body tissue|

---

EP3360474A4|2015-10-10|2019-07-03|Shenzhen Mindray Bio-Medical Electronics Co., Ltd.|Medical intensive care system, method of displaying intensive care data, and intensive care data display device|

---

EP3367892A4|2015-10-29|2019-06-19|Lai King Tee|A system and method for mobile platform designed for digital health management and support for remote patient monitoring|

---

CN106845053A|2015-12-04|2017-06-13|北大医疗信息技术有限公司|Medical data display methods and device based on HTML5|

---

US10818381B2|2015-12-08|2020-10-27|Datica, Inc.|Electronic medical record integration system and methods|

---

US20170323055A1|2016-03-31|2017-11-09|Zoll Medical Corporation|Charting logic decision support in electronic patient charting|

---

USD831037S1|2017-02-13|2018-10-16|Jakob Gottlieb|Display screen or portion thereof with an animated graphical user interface|

---

CN107133454A|2017-04-20|2017-09-05|无锡慧方科技有限公司|For the method, system and computer-readable recording medium that medical data collection is scanned for and counted|

---

US20180330060A1|2017-05-15|2018-11-15|Clarity, Llc|Systems and methods for transforming patient data by a healthcare information platform|

---

US10957445B2|2017-10-05|2021-03-23|Hill-Rom Services, Inc.|Caregiver and staff information system|

---

US11108865B1|2020-07-27|2021-08-31|Zurn Industries, Llc|Battery powered end point device for IoT applications|

法律状态:
2018-03-27| B15K| Others concerning applications: alteration of classification|Ipc: G06Q 50/00 (2012.01) |

---

2018-11-13| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2020-02-18| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-08-18| B11B| Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements|

---

2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US201361771591P| true| 2013-03-01|2013-03-01|

---

PCT/US2014/018987|WO2014134293A1|2013-03-01|2014-02-27|Systems and methods for integrating, unifying and displaying patient data across healthcare continua|

---